I am learning multi threading in Win Forms using C# and according to sources the best way to achieve this is by invoking the main method from worker threads.
Now this all works good when heavy processing must be done and THEN the GUI is updated.
However I have a scenario where I need to programmatically add lots of controls inside a panel. This may go up to thousands (panel will be scrollable). Hence, since the controls are ultimately being added by the main thread, the program still hangs until this has been completed.
Is there any way around this? Or should I try and use some other control which doesn't require me to instantiate lots of controls simultaneously (as this is obviously a bit heavy).
Basically this panel contains a list together with an icon (depending on the state). Hence I am creating a label for every entry which I do not know if it the ideal way.
By the way I come from the web applications development department... Is there a control similar to a div in .NET? I looked at a rich text box but it doesn't seem to let you add an image in a straightforward way.
Thanks in advance.
You shouldn't have a good reason to add hundreds of controls, let alone thousands. It sounds like you need a custom control and you need to add items to it.
The ListBox or ListView control will work for a basic item but if you want lots of customizability you will have to reinvent the wheel yourself and draw everything manually. It's a lot of work if you need to handle multiselect, scrolling, keyboard shortcuts, etc.
This is the strength of using WPF instead of Winforms since you can easily use the existing ListBox logic and have free range to customize the appearance of the items and even how they are arranged.
WPF has the concept of a virtualizing panel which can perform well even with thousands of items since it doesn't create the UI objects until an item is scrolled to.
I have this application:
I want to change the marked area when the user is clicked one of the navBarItems (like Microsoft OUTLOOK). I've been doing some research and a lot of people said that I can add several panels and show/hide them when user is clicked a navBarItem. But the area will contain a lot of gridviews and a lot of other controls. I don't know if I want to initialize all of them when application starts because it's gonna be hard on the cpu and memory to keep all the controls running at the same time. And I don't think it's an elegant solution for this kind of situation. But if I choose to initialize controls when user is clicked to corresponding navBarItem, it's gonna be laggy for the user.
What is the best design approach for this situation?
PS: I can use commercial libraries too.
Thank you.
Does not necessarily have to be laggy. If you show the screen first and then populate the data in the background it may not look too bad for the user. Also, once a particular screen is initialized you might keep it in memory so subsequent times user navigates to it it will be faster.
Also, look at what data you are loading into each control. Is some of the data the same? Can you preload some of the data in the background and keep it around?
Do you have a lot of drop down lists? If so, can you prepopulate or cache some of the drop down list data to improve the performance?
Is there one or two of the panels that will be used a large majority of the time? If so you could preload these panels so the user has a better experience for the panels they will most often navigate to.
Background processing to load data will make your code more complex but that is going to be the best way to get good response time from your app.
Here is an example of running a background thread from the UI using Task.
And another one using the BackgroundWorker.
I want to take advantage of the async loading of data since it's possible my users could have latent connections. It is possible they pull back data numbering in the thousands of records and sometimes even more. I don't have a datasource available to me right now that would give me my thousands of records right now. I just want to confirm that a user would be able to see the contents of the grid or listbox while the rest of the dataset loads async in the background. It looks like data virtualization could be an option but the articles I have found have either been trash or based on an older version of SL. Does anyone have any links to and POC or examples of this behavior?
If I enable datapaging on my listbox would the first page of data display on the screen as the rest is being fetched? Or does it only load the data as the user navigates to the next page?
You can take advantage of Data Virtualization,
Make the number of UI elements to be created proportional to what is
visible on screen using VirtualizingStackPanel.IsVirtualizing="True".
Have the framework recycle item containers instead of (re)creating
them each time, by setting
VirtualizingStackPanel.VirtualizationMode="Recycling".
Defer scrolling while the scrollbar is in action by using
ScrollViewer.IsDeferredScrollingEnabled="True". Note that this only
improves perceived performance, by waiting until the user releases
the scrollbar thumb to update the content. However, we will see that
it also improves actual performance in the scenarios described below.
The above text is from the excellent Data Virtualization document by Bea Stollinz, written for WPF but should be adopted in Silverlight too.
You may also take advantage of .NET asynchronous programming model such as the IAsyncResult, TPL and the EAP.
I have a WPF application, and it's slow.
It is NOT the rendering. Firstly, the rendering is quite simple, and secondly, I looked at it with WPF Performance Toolkit - nothing.
It is NOT in my own code. Firstly, the unit tests work fast, and secondly, if I replace all DataTemplates with blank ones, everything works fast.
So far, it looks like the slow part is template instantiation. That is, when you start the application, and open some complicated screen, it takes a lot of time. And by "a lot" I mean "a lot". Sometimes can be as much as 3-5 seconds - for example, when there's a datagrid with 100 rows. But when you go to another tab, and then go back to that same screen, it opens fast (as long as its viewmodel stays put).
This is very annoying not just because it's slow, but because I can't do anything about it. If I had some control over the slowness, I could, maybe, display some "opening, please wait" message or something...
Besides, when I look at some other WPF applications (most notably, ILSpy), they seem to work reasonably fast, despite the large amounts of data. This makes me believe that I'm probably doing something wrong. But I have no idea where to start.
Any ideas? Any classic mistakes? Any tips?
My exerience comes from working on the WPF mind mapping application NovaMind
A couple of months ago we completely rewrote our intermediate layer to solve the performance issues we had experienced. In a nutshell, creating our user controls seemed to be way to slow. Unfortunately I couldn't find a great way to profile the performance as neither the WPF Performance Suite nor commercial applications such as ANTS Profiler give you any detailed information on this part of the WPF process. (I asked this question back then)
We resorted to manually test our application by trial and error and removed parts of our user controls to see what exactly is the culprit.
In the end we solved the performance issues by completely rewriting our controls. We also cut down on the complexity of our visual tree dramatically. Before the rewrite, one of our most used user controls, when inspected with Snoop, consisted out of 61 different things, now there are only 3. Wherever possible we only added things to the visual tree on demand. (As you know in XAML even when you set things to Collapsed, they need to be created first).
Finally we were forced to write our own rich text rendering control as the built in RichtextBox is ridiculously slow and the visual tree of the RichtextBox is quite complex.
I don't know if this will apply to your situation but I would recommend that you investigate your user controls and see if they are complex. Maybe you have things that you could trim.
Low hanging fruits would be parts that are only rarely visible or can be created in a lazy manner. You could create these parts from code behind when necessary rather than having them in XAML. This should help you a lot.
Otherwise virtualization is your friend, if possible. In our case we couldn't do that unfortunately.
This sounds similar to a problem i was having. I posted the fix here: WPF UI Automation issue . Just posting for the benefit of searchers, as it took ages to resolve.
Following comment on link only answer, here is the crux of that post:
I did the following:
Downloaded Hotfix - - http://archive.msdn.microsoft.com/KB978520 (may not be required)
Downloaded Hotfix - - http://archive.msdn.microsoft.com/KB2484841 (definitely required even if you have Windows 7 / .NET 4)
Improved the code further (the validation was causing an excess of objects) - Why does WPF Style to show validation errors in ToolTip work for a TextBox but fails for a ComboBox?
It may be that only Number 3 was required, but it worked. Just posting here so people dont lose the days I lost in memory profilers etc.
User Control in your data template, is not completely bad idea but if you crave for performance then you should consider switching to lighter control. For example, having a UserControl just hosting a TextBox is very bad idea, as UserControl is made up of ContentControl, ContentControl hosts ContentPresenter and ContentPresenter will host TextBox so if you notice your Visual Tree, it has three new layer of UI Elements. Reducing Visual Tree will certainly improve the performance.
Most likely, I would suggest creating Custom Controls that may be a completely a new control having few dependency properties that can relate to data you want to present and you can have its own custom template in generic.xaml. Second, you can just simply derive a control from existing controls and redefine its default template in generic.xaml.
This approach will certainly work better as you will be reducing your Visual Tree, thus reducing Visual State Manager's job.
Changing theme or template will be slower then changing the element that hosts content. And let the element have the default template in its own generic resource dictionary.
Try moving all the resources up as
far as they'll go, preferably into
app.xaml
Check if you could use StaticResource
instead of dynamic ones, static ones
are alot faster
If possible, try using depedency
properties in your VMs, especially if
you have alot of them at once or if
they have alot of properties. That will keep wpf from having to do a bunch of reflection.
You mention you are using a DataGrid with, say, 100 rows. A likely culprit of your perf problems is that whatever datagrid you are using isn't doing virtualization, and so your visual tree is gigantic.
Normally, long startup time in WPF screens points to a large visual tree.
I'm not sure if you're using a datatemplate per row, or some 3rd party grid that binds columns, or what - but lets say you have 8 columns with controls. Depending on your grid/validation/etc, this could be a visual tree of 20-60 items per row. If you have a combobox, then each item in the dropdown may be created per row as well.
To fix this just takes watching the details, and taking measures as you go:
Use a virtualizing control as much as possible. This means using a virtualizingstackpanel inside list controls, and making sure your 3rd party controls do as well (many stock WPF controls do now by default)
Do not overuse UserControls, composite controls, etc. Adding depth adds time, and putting in extra visual tree depth in a datatemplate or other repeated area adds up fast.
If all else fails, show a simple screen and add controls through code to improve perceived performance
I'm working on a media library mock-up and I have a database of songs (over 9,000 tracks) that I want to display and make sortable. I'm not sure which GUI control would be best to use and I am not sure how it would be best to add all of the entries to the control.
Obviously using a listview and adding each entry one at a time takes a long time. Currently, the database is returning all of the tracks in an array of media objects (mediaEntry[] - a struct I defined). I don't know much about .NET's databinding system and any performance benefit that may bring.
The database is also searchable so I'll be changing the information displayed in the GUI control depending on the search terms.
Something like DataGridView or ListView in "virtual mode" should work well; this avoids the need to process all the data up-front.
however - I doubt that mediaEntry should be a struct - sounds like a class to me.
It is very rare you write a struct in .NET
The Listview control has a virtual mode, where you supply the viewable data on demand. Its actually easier to use than it sounds. Checkout the VirtualMode property and the RetrieveVirtualItem event.
You may want to give ObjectListView a try. It's very handy to use and has excellent performance when used appropriately.
Note: I'm not the developer of this library, I'm advertising it just because I used it in one of my projects.