I am making an app with large set of data, to improve performance I used virtualizing stackpanel inside listbox. Now I have better performance but loading items as they roll in becomes slow when I scroll fast. I am interested:
what is default number of rendered items? (without those in viewport)
can I and how to set explicitly number of items to be rendered at the same time?
Currently three items can fit the viewport, I guess that it renders 5-7 items at the time. How can I modify it?
Related
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
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.
When we build Universal app for Windows 10, in order to support multiple resolutions we can use Adaptive triggers.
In this case for each visual state, separate layout is used. If we have 3 sizes to adopt, for each layout must be created, and as a result for most controls there will be multiple duplicates, which are hidden and becoming visible for appropriate visual state.
All these controls will be loaded to memory and waste RAM, which can be dangerous for low memory mobile phones (like lumia 620).
Is it right solution to use separate view for this case?
Update
If someone needs, here are good and very simple articles about element layout reordering form wintellect (AdaptiveTrigger, changing element positions in grid) and galasoft (AdaptiveTrigger, RelativePanel).
Windows 10 Xaml introduces an attribute x:DeferLoadingStrategy to mark controls to be loaded only when needed. This will let you include all of the controls in the Xaml without loading them into memory unless and until they are actually used. In the mobile case where the device is likely to have only one size actually used (or two for portrait / landscape) the layouts for the other sizes will never load.
For the case where you are using the same controls but just have slightly different positioning I would look at moving them (possibly with RelativePanel), as Jon Stødle suggests in the comments.
If there are bigger changes then I'd look into separate layouts (like you're doing) within the same file or with separate Xaml, but for simple positional changes that's probably overkill.
I'm trying to optimize the loading time of my website.
Does requesting the same image in different places of the code increase load time?
For example, I'm using an image as background of a button and I'm loading the same image in different places of the website.
Is this a problem or since the file is the same in all the buttons the browser only loads it once?
If it's a problem, how can I optimize it? Thanks a lot!
no, repeating the same image multiple times should load it only once. You could even go further and actually use css sprites to have multiple images in one (one image which is a grid of images as a background within a smaller containing div and move it around with background position property)
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.