Develop Reference

How to make a heavily populated C# Windows Form UI more responsive

I have Windows Form that I use for a trading application, which, of necessity, has to display a large amount of information updating very rapidly (4 times per second).
The Windows Form I'm using has lots of controls (over 150 buttons and textboxes), and 6 datagridviews with multiple rows to display the information.
I have using different threads to perform the time-consuming operations (HTTPRequests, and various mathematical operations), but I am still finding that the GUI feels sluggish. I've noticed, in particular, that when I add more controls to the Form, things slow down, even though these extra controls are really 'doing' anything.
Can anyone explain why the mere presence of extra controls should make the GUI less responsive and/or recommend a completely different approach? Maybe I shouldn't be using Windows Forms?
Thanks.

It is hard to say something concrete without knowing your code.
A few generic ideas:
From your description, it sounds to me, like your application is very busy with repainting all the controls. Try experimenting with SuspendLayout() and ResumeLayout() and Invalidate() only those Controls that really need repainting.
Check if DoubleBuffering is enabled on both the Form(s) and ChildControls, it should be activated for most controls by default. But make sure you have it on.
Depending on your used .NET Frameworkversion check if you can use async/ await features for keeping the responiveness up.
See article MSDN Magazine article "Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads". This one is a few days old, but still absolutely valid.
Some events are fired more often than you expect or need. Check those events that cause repainting of controls (i.e. this will be where you add values to be displayed to the user) if these fire too often.

Your controls take a lot of memory and I wonder why you have so many, have you considered creating controls on the fly as and when needed. Double Buffering is a must but will not help if you are clogging up memory as it is for graphic display. You need to profile your program using performance counters to find out where the problem lies, are you disposing correctly for instance?
Also are you using too many threads? Are you using the thread pool, if not you should be!
Are your controls loaded with data?
I will think some more but profiling is what you need to do next.

Increase performance of WPF controls loading resources

I currently use DevExpress controls heavily in an application. The controls are great and speed-up development time dramatically (and hence, I wouldn't want to ditch them) however, I have a few issues with their performance.
My application is a Shell/Modules/Views&ViewModels application (it follows a lot of the design patterns you would find in Prism).
When a view is first loaded it takes an extremely long time to display (on some of my users PCs with slow machines we're talking 5+ seconds of just hanging there). The time it takes apparently depends on the usage of DX controls (how many ones are on there that haven't been seen before by the application).
When you destroy the view and re-open it, it opens in less than a second. The ViewModel in my test cases/performance profiles has been made to re-create each time - so there is no shared state within my code between invocations of the view (no singleton injected objects).
After a bit of discussion and research I appear to have narrowed down the problem to on-demand loading of the template files for the DX controls.
There is a thread here about that:
http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=Q382256
which references:
http://www.devexpress.com/Support/Center/p/B201967.aspx & DevExpress controls for WPF load time
The solution described in these threads is to either display a loading indicator or to use a hidden window with controls on it at start-up. Neither of these options are something I'd like to do (and the hidden window option didn't appear to gain much performance when I tried a simple example, interestingly - which also suggests that I might be missing something).
What I am hoping to do is to pre-load template files that I know I'm going to need on a background thread. Is there any way I can do this in WPF? (I'm thinking this is more a general WPF thing rather than a DevExpress thing - even if it's something that needs to be implemented in the DX libraries themselves).
Any ideas for either me or the guys at DevExpress?

What you can do in the background thread is to preload all the required assemblies. Also make sure they are nged-ed. The UI controls need to be initialized from the UI thread.

How can I speed up ListBox rendering and ListCollectionView filtering?

A two-pronged question here, but I think these two subjects are entwined enough to warrant their inclusion together.
In our application, we have a ListBox, which is populated with what might be a large number of items. Each of these items is displayed with a rather complicated item template. It's necessarily rather complicated, and while it could potentially be pared down a little more I probably couldn't take a huge amount out. The items in the ListBox come from a ListCollectionView which is constructed from an ObservableCollection<> of the objects to display.
We have two problems.
The first is that when we reconfigure filters for the ListCollectionView and call Refresh on it, there is a very noticable lock-up of a few seconds in the UI while it's torn down and recreated, and the ListBox repopulates. The duration of this lock-up seems to be related to the number of elements contained in the ListBox, and is longest when the ListBox's client area is full of items. We're pretty certain that the lock-up is caused by the item templates being recreated. I have tried turning on virtualization, but this had no effect in reducing or eliminating the slowdown. I'm also looking at some other optimizations, like examining our bindings and modifying the layouts. Is there any method for either avoiding this particular issue, speeding it up, or moving it to a different thread? (I know the last one's highly unlikely because the rendering is all single-threaded, but perhaps there's some workaround...)
The second relates to the filtering on the ListCollectionView. While it isn't an issue at present, we think that there's potential for the filtering to become an issue and cause a noticeable lock-up on the UI thread. I am working to reduce the filtering overhead, but I was wondering if there's a method for moving the Refresh call on the ListCollectionView on to a different thread? None of my attempts thus far have succeeded, seemingly because the ListCollectionView doesn't automatically marshal certain events on to the correct thread.
Pointers to or explanations of any known or potential solutions to these two issues would be very helpful.

Some interesting ideas in this SO thread about datagrid rendering and binding - you may be able to apply them to your listbox scenario as well...

I don't think you can virtualize AND filter at the same time. So, if I were in your shoes, I'd stick with a virtualizing list box and do the filtering logic in another thread. Sure, you might have to write some code that's already been written before, but if it doesn't lock up your GUI? Worth it.

2 tips from here, the first one might help for virtualizing the ListBox:
Virtualize lists and views by using a VirtualizingStackPanel as ItemsPanel for lists. This only creates the visible elements at load time. All other elements are lazy created when they get visible. Be aware that grouping or CanContentScroll="True" prevents virtualization!
Enable Container Recycling. Virtualization brings a lot of performance improvements, but the containers will be disposed and re created, this is the default. But you can gain more performance by recycle containers by setting VirtualizingStackPanel.VirtualizationMode="Recycling"
I did virtualization of my huge list of objects by the technique described here on codeproject, it works nicely

How to create a fast WPF Datagrid control from scratch?

I have been using a number of commercial WPF datagrids in the past and I must say the performance has been quite disappointing and slow. I would like to be able to load up up to a million records and be able to scroll up and down fast without any lag.
I have been told by some Guru WPF developers that it is indeed possible to create a WPF Datagrid from scratch - with far less features than the commercial ones - focused mainly on performance.
But how would I proceed? I have been told developing these datagrids should not be built in the usual way of utilizing the ItemsControl, which leads to the same performance problems as the existing wpf grids.
Is a Guru here to point me into the right direction?
Update:
Because one person mentioned the doubt of needing one million records, now too many are jumping on the same bandwagon. What I am interested in is creating a low latency fast Datagrid with barely any feature, which can hold in theory up to a million record.
I dont require any sorting, filtering or else, all I need is speed. And thats where I needed guidance from a Guru. I know what Data Virtualization is, its just not enough.

I suspect that you want to look at the VirtualisingStackPanel as part of your implementation, it only renders controls as they become visible.
However, a million records sounds like too many for any user to seriously need on screen at any one time. I'd seriously rethink my UI design but that's just me.

Methodologies used to speed up the process of creating and coding subforms

My question is how programmers create, code, and organize subforms in general. By subforms, I mean those groups of controls that make up one UI experience. I'm looking for hints to help me better organize my form codes and to speed up the process of creating such forms. I swear to God, it takes way too long.
I've identified three broad groups of subform elements:
-Subforms have commands to do something.
-Subforms have data elements to carry out those commands.
-Subforms have states used to track things that aren't data.
The approach I use is to focus on what it takes to perform the commands which will determine which data elements are needed and how they should be validated.
Also, do programmers use check lists when creating forms?
p.s. I program as a hobby.

This is incredibly fuzzy. There is however a red flag though, you seem to be talking about UI as a starting point instead of the end result. That's a classic trap in winforms, the designer is rather good and makes it way too easy to endlessly tinker with form layouts. You forever keep adding and removing controls and event handlers as your ideas about how the program is supposed to work evolve.
This is backward and indeed a huge time sink. Effective design demands that you grab a piece of paper and focus on the structure of the program instead. The starting point is the model, the M in the MVC pattern. As you flesh out how the model should behave, it becomes obvious what kind of UI elements are necessary. And what commands should be available to the user.
The V emerges. Instead of jumping into the designer, sketch out what the view should look like. On paper. Make a rough draft of an organized way to present the data. And what operations are available to the user to alter them. Which selects the type of controls and the menus and buttons you'll need. Once that congeals, you can very quickly design the form and add the C. The event handlers that tie the UI to the model.
There's a very interesting tool available from Microsoft that helps you to avoid falling into this trap. I love the idea of it, it intentionally makes the UI design step imperfect. So you don't spend all that time pushing pixels around instead of focusing on the design of your program. It draws UI designs in a paper-and-pencil fashion, there are no straight lines. Incredibly effective not just for the programmer, also a "keep the customer focused and involved" fashion. So that the customer doesn't fall in the same trap either, nagging about a control being off by one pixel. It is called SketchFlow, link is here. It is otherwise the exact same analogue of paper and pencil, but with a 'runs on my machine' flourish.

Try CAB I'm not sure you should use it, but the pattern will help you understand how to write your gui layer in a good way.