koobas.hobune.stream
Best approach for a large scrolling list
I have a situation in our game where we want to select players from a list of the users facebook friends. We use our own GUI system that makes up each entry in the list from a backing texture, the avatar image and some text labels in 3D. My existing system can scroll a number of these "panels" up and down by generating them all and moving their single parent.
However if a facebook member has 1000 or even 5000 members I fear that pre-generating that many panels would be both memory hungry and even if most don't draw there will be a per object overhead.
Does anyone have any suggestions of other approaches I could try? I am thinking of writing a solution where it uses just, say 10 panels, and reuses these over and over but I think this will be a huge task as some panels can also have different things in them, such as buttons and other extra images.
What target platform? Does your own system use any form of texture atlas? For "text labels in 3D" how are these generated and textured? How big are the avatar images? How do you plan for the user to navigate when the list becomes long?
If it were me, I'd fake up some data so I could generate a list that was 1000 and 5000 long to see where I had issues. $$anonymous$$y guess is that for up to 1000 entries you would be okay generating the whole list, but deferring the loading of images. That is, images are loaded and unloaded as that become near to being seen.
Its for mobile devices so you'll see 5-10 entries on the screen. Our system doesn't use a texture atlas. A good example is the friends list selector in "Scramble with Friends". This shows a similar amount per screen, allows for normal flick scrolling and adds a scrollbar button to allow you to drag it to the bottom of a long list. We are currently using the dynamic fonts of Unity4 with Text $$anonymous$$eshes, but this may become fixed fonts if we see performance issues. We are planning to load the avatars "on-demand" as you suggest.
Using a texture atlas for some common items on the list might help...even if you have to code it by hand. I wouldn't write off building the whole list until you tested it. I wrote a test app a year ago that displayed a book inside unity. It used a bitmap font displayed using meshes. Performance was fine on the iPad. Never tested it on an iPhone. You may find that scroll and memory usage is fine, but that layout takes too long for reasonable use. Or that all three work, but it is just too painful to scroll through and find someone in a list of 5000.
I too am interested in this capability. $$anonymous$$y limited understanding would be use something like Futile for the 2D batched rendering with a bitmap font to draw the text in the list. Given only say 10 rows are visible on screen it needs to have a set 10+1 more 'row entities' that are recycled. I.e. as one scrolls out of the frustum at the top it is moved to the bottom and the row info is set to the new information. $$anonymous$$y concern is will floating point errors start being an issue when it's 1000+ rows long, or how stable is the memory allocation/freeing for large async lists? Personally I'd love to jointly write this with someone as it's quite a bit of work getting the 'flicks', async loading/unloading, edge fading, scroll bars, etc..
@sradforth - You might try a full list implementation first. I don't know your platform, but I wrote some list code and tested it by displaying a novel on an iPad 3 (using a bitmap font). Load time was under one second. No performance issues. Even if you wanted to conserve memory by dynamically creating the font, you could still do the layout of the whole list (assu$$anonymous$$g fixed height entries). For collaborations, see the forums.
