mherger wrote: > >> 3410 Artists, 2531 Albums, 30,000+ Tracks > > > > Wow! That's a lot! That will *definitely* need some splitting up for > the > > UI to still be responsive! I'll implement the letter grouping in a > later > > release. > > Isn't there an option to "lazily" render items in a long list? Eg. it > could only render the currently shown items, plus a buffer before and > after them. Anything else would dynamically be added/removed. >
The items are already 'lazy' rendered. I fetch them in batches of 100, when you scroll nearer the bottom, the next set is fetched, etc. The issue is that then all currently fetched items are part of the HTML DOM, which (I think) would start to slow things down. I have experimented (and previous releases used) a 'view recycler' library - where only a portion of the current list was part of the DOM. This had issues where navigating down into the bowse page, and then back up, some items would not be shown. Hence I disabled this for now, and will re-add later. I have many things to do, so optimisations should probably come later. I was using an older version of the library, as I could not get newer versions to work - so this might be fixed in the lib itself. mherger wrote: > >> 3. I have a largish library. Scrolling from A to Z takes a long > time.[color=green] > > What I could do is group A-Z listings in blocks of (e.g.) 100 items. > So > > Using SlimBrowse IIRC there should be "textkey" information. Information > > which can be used to create an index to jump by first letter quickly. Yes, I've seen this - and this is what I was going to use (its also in the non-SlimBrowse calls). What I intend to do is give an option to divide Artist and Album lists into letter groupings. Then I'll fetch this 'textKey' block and create that number of sub items, and list entries under that. e.g. Artists > A > Abba, AC/DC, etc. Using it as a 'jump list' into the browse list is possible if I create all view entries on initial fetch, and only populate the currently visible data. This is possible, but I still worry that 3000 items is a lot for the DOM. Hence thinking that splitting them up makes more sense. As an aside, seeing as the current browse method works, I intend to leave it like this until most of the other features are implemented, and then I will go back and replace app listing, etc, with SlimBrowse. ------------------------------------------------------------------------ cpd73's Profile: http://forums.slimdevices.com/member.php?userid=66686 View this thread: http://forums.slimdevices.com/showthread.php?t=109624 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
