When you have 200+ games on your Switch and you try to use the sys-clk manager, the framerate is down the toilets and RAM usage is up to the roof. That is because 200+ list items are allocated and drawn (they are clipped when out of view, but still), with each list item its own thumbnail.
To solve that problem, we need to implement the same recycling mechanism as Android has:
Image credit to https://alexdunndev.files.wordpress.com/
This works best if all views in the list are the same.
- On screen you always draw just enough views to fill the screen, that would be about 4/5 for the above diagram -> that's the framerate efficiency
- You keep some unused views to avoid allocations when scolling, but views that are out of the screen don't actually exist -> that's memory efficiency
- When you scroll, you recycle existing views and change their data (so change the label text, the image source etc...) to make it LOOK like it's scrolling to the user
Here's how to implement it in borealis:
- Make a
RecyclingList view
- Make an
RecyclingAdapter interface, containing three methods: one to allocate a new view, one to "bind data to a view" and called when the view is "thrown away"
- Make a convenience adapter class for XML views
XMLRecyclingAdapter, which implements the "allocate a new view" part from a given XML file
- When creating a recycling list view, you give it an adapter
- The "allocate a new view" method gets called everytime a new view is needed (on creation, if the screen is resized, or if an abnormally small view gets added, adding the need to a new one to fill in the gap...)
- The "bind data to a view" method gets called everytime the user scrolls enough for a new view to come in, before showing the view
- The "thrown away" method is called everytime a view slides out of the screen, before returning to the views stash
The user is responsible for handling resources in the adapter code. If there are images to load for instance, they have to be unloaded in the "throw away" method, and loaded back in the "bind data" method. It can even be asynchronous if loading the image takes time (provided the Image class allows it 👀 ).
Or the implementation can be naive and everything can be stored in one big std::vector... in which case the framerate will stay fast, but the memory usage will be high. That's up to the user.
When you have 200+ games on your Switch and you try to use the sys-clk manager, the framerate is down the toilets and RAM usage is up to the roof. That is because 200+ list items are allocated and drawn (they are clipped when out of view, but still), with each list item its own thumbnail.
To solve that problem, we need to implement the same recycling mechanism as Android has:
Image credit to https://alexdunndev.files.wordpress.com/
This works best if all views in the list are the same.
Here's how to implement it in borealis:
RecyclingListviewRecyclingAdapterinterface, containing three methods: one to allocate a new view, one to "bind data to a view" and called when the view is "thrown away"XMLRecyclingAdapter, which implements the "allocate a new view" part from a given XML fileThe user is responsible for handling resources in the adapter code. If there are images to load for instance, they have to be unloaded in the "throw away" method, and loaded back in the "bind data" method. It can even be asynchronous if loading the image takes time (provided the Image class allows it 👀 ).
Or the implementation can be naive and everything can be stored in one big std::vector... in which case the framerate will stay fast, but the memory usage will be high. That's up to the user.