I'm working with a List in Office Fabric, specifically a DetailsList. Within my list, I have a number of images that are pretty expensive to render, as well as a pretty big list of rows. Unfortunately, this means when I scroll down, there's a huge lag as the page is re-rendering new images (also frustratingly because it destroys the previous images, if I scroll back up it's similarly laggy).
Is there a way to force a render of the entire list so that it doesn't have to re-render when you scroll up or down? I don't mind having a long initial loading time as long as the actual scrolling portion doesn't have a high latency/isn't slow or jerky.
You can disable virtualization by returning false in the DetailsList's onShouldVirtualize callback.
The team is actively working on improving List / DetailsList virtualization in the coming months.
Relevant documentation pages describing the above prop:
https://developer.microsoft.com/en-us/fabric#/components/detailslist
https://github.com/OfficeDev/office-ui-fabric-react/blob/738e270892f99957aecf567e4b107f8e4cf86176/packages/office-ui-fabric-react/src/components/DetailsList/DetailsList.types.ts#L253
Related
To be short, my requirements are:
The list needs to contain about 5 thousand average product cards in two columns. The products are splitted into sections.
It must be performant, really performant
I need it to work well with onViewableItemsChanged method
I need to be able to scroll it to the desired position as quick as possible
It must be able to be Animated with the native driver (e.g. to animate header according to the scroll position)
I've tried to use SectionList for my purpose, but it did not achieve the desired performance despite many tweaks of the virtualization parameters. The problem was that the responsiveness of the app gradually got worse as I scroll down. It was because of the amount of items above the viewport. Yes, SectionList do detach the items outside the viewport, but it replaces it with the getItemLayout function, which floods the thread and hangs the app for about 3-4 seconds before it starts responding.
Another way I tried was to use react-native-big-list. This thing works really well with lists like mine, like really fast, exactly how I need it to work. But sadly it is not perfect and has some unsolved issues:
the onScroll method here does not work with Animated.event with the useNativeDriver prop set to true
the onViewableItemsChanged stops working as soon as I reach the second section of the lists
the scrollToLocation method does not support the viewOffset prop.
All the issues above are known but still not resolved, and I am not as good to somehow patch them (in fact I tried)
I do hope that someone have the same problem solved.
Sorry for my mediocre English, but hopefully I expressed my thoughts good enough to be understandable
I use a flatList to make my activity feed.
However, I have a problem with the fluidity of my list
Each item can render up to 80 static images of 25kb, each in an absolute view, I still have to play with the performance when I mount my components but when I scroll, if I have my 80 images per item, my list is absolutely not fluid!
However, when I check my rendering number, I have very few because I use PureComponent for my items.
I check the RAM, and everything looks good!
My UI and JS Threads are constantly at 60!
Could this be due to the number of views I see in "Perf Monitor" that goes up to more than 3000? If it's that, how do I fix it?
Hoping to have a solution,
Thank you
Viktor
I've been facing the same issue , but after reading docs ive implemented the below :
You can use the community packages (such as react-native-fast-image
from #DylanVann) for more performant images. Every image in your list
is a new Image() instance. The faster it reaches the loaded hook, the
faster your Javascript thread will be free again.
You should always use react-native-fast-image for more images.
Hope it helps. Feel free for doubts
I had issue in my android version. I set resizeMethod="resize". This gave me massive performance boost.
I was loading lot of large images in section list and FlatList. Using resizeMethod as resize resolved my issue, and scroll is buttery smooth after this.
I am trying to display a large matrix that is constructed of 0/1, each cell is a div which could be black or white, when trying to display matrix of size 1000x1000 the browser crashes...
I am using v-for nested with v-for to display it...
how can i improve the performance?
This is not a Vue-related problem, but rather a DOM related problem. You are putting over a million DOM elements on a page. A tab where I ran a test that generated a stable 1000x1000 matrix with empty divs and classes showed that it consumed 2.3GB of memory. It took quite some time to even render, and scrolling is very slow, which suggests that it is the browser that is having trouble here. Vue does not do anything in my test after having rendered the page.
What you can do depends on the use case. If you just want to display data in a graphical way, consider using a canvas. You can freely draw on a canvas, and since you do not have to juggle around a million dom elements, the performance should be much better.
Other techniques include lazy loading, where you use scroll position to only load/show the rows that are in the viewport. This will reduce the number of dom elements, which should increase performance.
Alternatively you can limit the amount of data that is served to the user, by providing a filter or something similar. If a filter matches too many items, you can cut it off at a certain number of items you know will render fine in a browser and show a message that some of the results are hidden for performance reasons.
In an attempt to optimize my app's performance, I've tried to cut down the number of elements in its main carousel as much as possible. I'm down to 3 first-order items (the one being viewed, along with N-1 and N+1).
I'd also like to cut out most of the contents of the N-1 and N+1 carousel items and programmatically add the contents for the item that is currently being viewed (so that the carousel items would look like this: http://i.imgur.com/gm7cL7E.png).
activeItemChange is the obvious choice here for the event listener. Problem is, it apparently is relatively slow, especially on low-end Android phones. It can take as long as 4 seconds to fire.
I've tried the carousel's onDrag property as a different way to fire the content creation, but asking the phone to do two operations (animate the carousel moving & create the new content items) makes the carousel movement animation choppy.
Is there any way to modify activeItemChange or the carousel to improve the listener's firing speed? Or any other listener I could be looking at that would perform better? I've done quite a lot of work optimizing overall performance on the app (shrinking the DOM, event delegation, etc) and the rest of the app runs quite well, so I'm not sure that doing general performance work will free up sufficient CPU to get activeItemChange to the level that I'd like.
Edit: I've done even more performance improvements in an attempt to free up enough CPU, to no avail. Any additional tips would be greatly appreciated.
Edit 2: It's been suggested to use order: 'before' for the event, as in:
listeners : {
order : 'before',
activeitemchange : someFunction
}
That does fire much more quickly. However, since activeItemChange has necessarily not been fired yet, I can't determine which item should get the carousel contents added. If I could determine which direction the carousel is going, that would be sufficient, but I can't seem to get that either.
Additionally, since Sencha seems to automatically paint N+1 and N-1 and erases N+2 and N-2, I was thinking I could use that as a more rapid determinant of where the item is in the carousel; unfortunately, based on the performance issues brought up in the Sencha documentation, it seems like it would end up with worse performance rather than better in the end.
Good question. Just a suggestion may or may not work. Instead of concentrating on the activeItemChange of the carousel maybe you could try the painted event of the container into which you want to put your items, or initialize event if the data is not going to change, initialize is faster than painted but only fires once so if your content is going to change use painted, otherwise try it out with initialize it may be the better way to do it.
I've been trying to render the entire canvas in an IWebBrowser2 control to a bitmap. IViewObject::Draw seems to be the most promising approach, but I can't get it to render anything that would requires a scroll to show. While I could automate the scrolling and stitch the images together, this would look weird with any fixed position elements. Is this even doable?
Additionally, I've tried to set the controller's size to one that would allow the entire contents to display without needing to scroll, but Windows caps the max size to the current screen resolution, so that only gets me partially there.
Any help would be much appreciated. I'm currently doing this in the context of Win7 and IE8, but I don't think that should matter much.
Sorry it took so long for me to follow up with the answer to this.
I wrote up an article detailing how to trick Windows into allowing you to resize a window larger than the virtual screen resolution, allowing functions like PrintWindow or IViewObject::Draw to capture the entire client area (i.e., the browser canvas).
http://nirvdrum.com/2010/03/25/how-to-take-full-page-or-full-canvas-screenshots-in-windows.html
An actual implementation of the technique can be found in my SnapsIE repository on GitHub (username: nirvdrum). Unfortunately I don't have enough karma to post two hyperlinks. The repository is linked from the article though.
It is very likely an IE optimisation that avoid to draw more than required. You might be able to scroll the window and call IViewObject::Draw in a loop without any animation occuring ?
I'm surprised that Windows caps the max size to the current screen resolution. Are you sure about that ?