What is best practice when rendering large lists

How-to Discussions
1

I have a StackPanel in a ScrollView with 150-250 rows that in turn contain 9-15 unique data items but a lot of similar styling aswell. All the data is passed to the view through an observable list. Scrolling is really fast, but setting up the view takes 3-5s where I would like it to be near instant. What is best practice with regards to memory and performance?

• Are there ways to provide caching hints?

• Should I layer the content in each row so similar design elements are grouped and unique data is composited on top of these?

• Should I avoid providing all the rows of data at once, and in which case, how does one allow scrolling through the list and exposing new data on the fly without hitting a “load more”-point?

I hope my questions make sense. I have tried to find some document or sample app that handles large complex lists but not found anything.

2

Go with the 3rd: http://creativitykills.co/how-to-add-infinite-scrolling-to-fuse-app/

3

If I create an infinity scroll it will break the scrolling motion every time I hit the bottom of the list because of the time it takes to render the new content.

4

Hi Sebastian,

Right the only best-practice strategy you can readily implement is to progressively load more data as you get towards the end of the view using <WhileScrollable>, like this:

<WhileScrollable Invert="true" ScrollDirections="Down">
	<Callback Handler="{feed.loadMore}" />
</WhileScrollable>

Unfortunately, this will indeed break your scrolling motion.

There are several things in flight that will make this better in upcoming versions:

  • The <Deferred> tag as a wrapper inside your <Each> allows you to spread creation of new items over several frames (from Fuse 0.25).
  • Automatic view recycling on Each (in progress, unknown release)
  • General optimizations to bring down view setup time
5

Thanks Anders! Then I know the state of this. I have experimented a bit and in my case view recycling would probably make the biggest difference. I have done some tests and it is the actual rendering, regardless if it is the same content over and over, that takes a lot of time.

Looking forward to testing to avoid locking the UI-thread, but it probably won’t be a final solution for me, because I need to scroll down a bit in my list and I think it will take 2-3 seconds until that part is rendered.

6

On a side note. Would be really nice if one could mark a ux:Class as a template which then gets cached. Then I could composite cached and non-cached classes to get fine grained control.

Would also be nice if there was a trigger because some things don’t need to be rendered during scrolling, and also for data and decorative elements etc.

7

On a side note. Would be really nice if one could mark a ux:Class as a template which then gets cached. Then I could composite cached and non-cached classes to get fine grained control.

This is basically what ux:Template does. Inside Each, things are implicitly templates.

I.e. the in-progress view recycling feature on Each automatically achieves what you imply here.

8

Is there an example with Each that renders a list with say 500 rows where each has non-trivial content and the view renders sub second?

Would be great to be able to compare with how my code looks and find where the rendering engine starts getting exhausted.

Or I could send you my project privately if that is easier.

9

same problem here :slight_smile:

i had to do workarounds to solve the render problem and i am happy that we now have the Deferred tag but I have a couple of problems:

In my non-trivial content i get weird results (but i will look at it deeply before posting an example (maybe the problem is having Each inside the deferred Each))

In a trivial content sample (i can post it here) results are not printed in the same order than the content is added. Most of the content is printed in the same order but some is printed at the end (even being the 4th out of 17)