I have a relatively large array (lets say 500 items) of complex objects and currently using md-virtual-repeat to render the UI and scroll though the items (of a fixed size) without a problem. Due to UI changes in the system it is required to add item expansion ability (resizing, something like collapse\expand for each item). For small arrays (up to ~20) the scrolling still works without issues. The problem starts for larger arrays and some items expanded. The scrolling becomes choppy and not all expanded data is shown since the virtual repeater replaces items while scrolling. I'm looking for a workaround of this issue, OR an alternative solution (maybe another library?). Any ideas?
Related
I have a ng-repeat that generates around 300 rows. I can't implement infinite scrolling since i need all the rows present on the page. For each row there are 3 elements.
When the page loads, i get all the rows from the database and if the element exists i display it, if not i have the option to add it by clicking on the place where the element would otherwise be. When clicked a form is displayed right under that element.
The form has 4 inputs, which is quite a lot of html. Now since we have two-way data binding, and we are inside the ng-repeat isolated scope, i can't use one form for all 3 elements (since the values in the inputs would be shared), i would need one for each. Considering the amount of rows, rendering so many forms takes more than i'd like.
To get a better idea of what i'm working with (visually, the code is not relevant anymore) http://plnkr.co/edit/xNYUbi?p=preview
I want to stick to the form dropdown under the add element option, so making a modal isn't an option.
How should i approach this problem?
I'm not certain I understand the specific use case here so I will give some generic advice that I hope helps. When working with lots of data angular, there are a number of options:
ng-grid: Has an edit mode and paging so with the correct settings you can pull down all your data, set the data source for the grid and the performance should still be pretty good.
ng-repeat: If you have to have a custom U/I or you need additional functions in your U/I, ng-repeat is about as good as it gets. As long as you don't have nested repeats (can be bad) and you craft your UI carefully you should mostly be all right.
Assuming that ng-repeat is still too slow you could think about implementing some form of paging or ng-infinite-scroll. With either option you can still load the entire data set initially and then display it in chunks rather than all at once.
At the end of the day - if the performance is unacceptable when you try to add all the elements to the DOM the only real solution is to alter the way those elements are added or simply don't add them at all (which is where all the above solutions really lead you). This might require talking to your client or going through a bit of re-design, but in the end it should be worth it. Best of luck!
I am about to build a new single page web application where I think the main view will be quite complex and I am tring to decide whether to use Angular.js. My concern is whether there will be too much data-binding causing the performance of the UI to become sluggish.
The app will have a view consisting of 2 panels. One will have 8 tabs each containing a table with 3 cols, 40 rows and one col in each row having a list of numbers (upto 4 numbers) where each number is clickable (clicking a number causes something to happen in the other pane). I was considering using the ng-repeat directive to dynamically create the tabs and tables and list of numbers from data provided from the backend as the content will be different for different users. So I think that would mean 8 * (2 + 4) * 40 (1920) items having watches added to the $watch list. I think this means that a lot of things will be checked each time round the $digest loop even although these items will never change once they have been created the first time.
The 2nd pane will have other tabs and items although not so many as in the first pane so over all there will be over 2000 items involved with data-binding if I use AngularJS and ng-repeat.
Is this too many items for one view when using AngularJS i.e. will the UI performance become sluggish with this number of items?
Are there any alternative ways of dynamically creating tabs and tables using AngularJS that don't use ng-repeat in order to keep the number of data-binding items down?
Some optimizations that i can suggest of would be
Look at bindonce directive. This does not create a watch once data is bounded. This should fix most of your issues.
Use directives like ng-if these destroy\create the DOM based on conditions. If a tab is not in focus what is the point having data bounded to it. Do binding just in time. And maybe destroy the page DOM once the focus on tab is lost (with ng-if) only.
Also test you app with dummy data, to verify how the real performance is and whether it makes sense to try the second option i have mentioned.
Here on StackOverflow is a great answer of Misko, talking about performance.
TL;DR: 2000 elements should be fine!
I got a pretty big form on a wpf page. I'm putting it together on a Grid, but all the element clutter the page. I figured i'd split out the form into smaller usercontrols and then piece it together on the page as one form. That didn't quite work: SharedSizeScope on a Grid makes the form 'dance'
I could break up the form into a 'wizard style' page, with a next button - dealing with each user control on its own, but i'd rather not break it up into several pages because the end user is used to having it all on one page. Also the validation/storing of data is really a big-bang operation, making it harder to provide feedback if something goes wrong in one of the first pages/usercontrols.
So what now? I'm really tempted to just put all the small elements directly on the page in one big grid. I just feel it's wrong - it will be a maintenance nightmare - i even started thinking 'i wish there were some kind of #region tag in xaml' - that means i know i'm wrong ;)
What can i do?
I would strongly recommend to use nested container controls, like Grids (or other Panels) inside other Grids inside more Grids etc.
It is very common to have several nesting levels, and thus hierarchically split a complex layout into multiple less complex sub-layouts. This makes your layout significantly simpler compared to one big container that tries to do it all (see your failed ShardSizeScope approach).
Once you have created a sensible hierarchy of containers, you may easily use the Visual Studio XAML editor's code collapsing feature to keep track of all your XAML.
At a high level my application is applying about 5 different DataTemplates to a set of ListBoxItems based on their type. These items are laid out on a canvas at specific x, y points. I implemented virtualization on my ListBox and it did not seem to improve the time it takes to complete the rendering thread's processes. It still takes about 8-12 seconds for the UI to be completely loaded and usable by the user. I thought virtualization would help fix this problem but after looking around it looks like it only helps process scrolling large amounts of data. Am I correct in this assumption and does anyone else have any other tips for improving the rendering thread. This is the only problem I am having and then my project is complete. Thanks StackOverflow!
Virtualisation means that only the items you have visible are created, then dynamically destroyed/new items created as you scroll. The alternative is all UI controls are created for all items at once.
It sounds like you have bigger problems with the rest of the app. Do you perform all loading operations on a background thread? Is the UI control tree very complex indeed? Are you displaying 100s or 1,000s of items?
We also had a lot of trouble with performance in WPF. Best way is of course to profile your application. We use ANTS Performance profiler for that, but any .NET profiler will do. We got a huge performance hit, because of the lookup of our XAML Resources. Thats the advice i can give you:
Try to minimize all resources in XAML. But not only that, also try to minimize the amount of XAML files you have. One thing you can try is to defere the loading of complex parts of your DataTemplate. Similiar to what happens when you load a JPEG in a browser, first you will see a pixelated image which will be finer after it finished loading the JPEG. To accomplish that, use a simpler DataTemplate at first and then if this is visible only load the complex template on demand or after a while.
But without more information of your specific problem, we can only guess. This is an old question of mine about a similiar subject, maybe this will help aswell.
Yes, ListBox virtualization is for scrolling. When you have a large number of items in a ListBox, enabling virtualization will make only the visible items (+ a few extra items for scrolling) render, and scrolling the ListBox replaces the data in the rendered items instead of rendering new items.
If you were to post some code, perhaps we could assist you with some performance tweaks
I hear a lot about the wrap panel being slower to load things and hence we need a virtualising panel.
Can somebody give me a small wrap panel sample where it can be proven it is slower to load etc that it needs a virtualising panel please.
I set a wrap panel as a panel control for a listbox, and added 10000 string objects to it, and it was not a problem. I am sure my sample was silly, maybe i have to write a business object and create a larger data template to see this problem in action.
Kindly show me a sample that proves wrap panel without virtualisation is slower.
Thanks.
I think the performance issue depends mainly on the number of visual objects in your tree.
The default ListBoxItem template consists of a low number of elements (a border and a textblock i think). If you have a template that creates a complex visualization of lets say 100 visual elements per item you get a fairly large amount of visuals depending on your item count.
This is the reason why the normal panel is slower at load time, because it has to create all the objects at startup whereas the virtualising version only creates visuals for the visible items and disposes no longer displayed visuals.
In addition this has also implications on memory usage
I recently needed this functionality when making a insert symbol form. Using a listbox with normal wrap panel as the items panel - load time would take up to 5 seconds.