I have a Canvas with ca. 100 Lines and Ellipses.
Now I add 100s of these Canvas to a WrapPanel. This process takes ca. 4-5 Seconds.
Is there a Way to add/load these Canvases asynchrony? I didn't found a way to do so and Dispatcher.Invoke doesn't work (because it is not asynchrony).
Thanks for any suggestion...
Not sure async is the solution here, as I read your question it sounds like you're adding many thousands of UI elements to the UI which are all triggering.
Still not much to go on but...
There is only one UI thread so any work that can offloaded elsewhere will improve performance.
try adding Debug.WriteLine to your logic and use a StopWatch object to time stamp them. You can trace where delays are being created.
review the code which sets up the lines and ellipses, how are you calculating any properties such as size and position. If this can be loaded into an array using an async Task method, you might get some responsiveness back.
are all the elements visible on the screen at the same time. If not, only load the ones that are by using a virtualizing panel.
If you need more pointers, you might have to share the code.
Related
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
Hopefully someone can help me or at least enlighten me a bit. After the release of the Mango Beta tools I have played a lot with the new WP7 Profiler and one thing does bothers me.
Every single listbox with just a bit more complicated items is taking forever to draw. For an example - a listbox that has item consisting of Border->Grid->6xTextBoxes (each showing single symbol) takes 303ms per listbox item. Of them 288ms are spent for the ListBoxItem's ContentPresenter Measure Time (excl.).
I know that Measure is kind of costly operation but still this is beyond madness. Any thoughts would be appreciated.
I can only confirm that MeasureOverride uses to be the most time-consuming operation. (And you don't need a profiler to find it out.) I can only guess why does it take so long.
First, MeasureOverride travels recursively through the visual tree of the ListBoxItem. Somewhere at the end of this call chain there's probably a call into native code that returns actual size.
Hence keeping simple item structure is of utmost importance.
Your structure seems to be overcomplicated. If you look at TextBox template, you will see that its structure is Grid > Border > ContentPresenter. I can't judge what is behind the ContentPresenter since I don't know your code, I just wonder why don't you use TextBlock (where possible) - it is so much more efficient.
As an experiment I would try to implement MyListBoxItem.MeasureOverride and return fixed size without calling base implementation. I have no idea if it works, but it could bring surprising results.
Second thing you may investigate when implementing your own list items is the frequency of the calls to MeasureOverride. (Or just look at the profiler output.) If the number of calls is too high, then the layout might take more loops than necessary. Perhaps there are some conflicting sizing requirements which need several steps to resolve.
You mention 40 items. That should not play any role. ListBox constructs around 3 screens of ListBoxItem's, remaining items are constructed (most often reused) on as-needed basis. If the Measure time increases by increasing the item number, then look for problem in the data implementation.
Make sure your data is fully loaded in an async action and only adding item to your ListBox is running on UI Thread
Make sure you use Grid instead of StackPanel in your template
The following article is also very useful:
http://blogs.msdn.com/b/slmperf/archive/2010/10/06/silverlight-for-windows-phone-7-listbox-scroll-performance.aspx
When I add many items to Canvas why does the UI freeze? Say I have a loop from 1 to 1000. I can only see all the elements after all 1000 of them are added. Why doesn't the Canvas show up items as they are added or removed one at a time?
What can I do to achieve this effect? I want to animate the elements as they are added to Canvas one by one at a time. But the animation doesn't show up because the UI just freezes.
Thanks in advance:)
Perhaps you could use a timer, and add a smaller number of elements on each tick? That would let you ensure a few refreshes between each add.
On one project with lots of shapes on a canvas, I found it was helpful to pre-allocate and add all the shapes at the beginning, then just toggle their visibility. I don't know if that's generally useful or just specific to the situation I was in.
In VB.NET, we use Application.DoEvents() but I feel it is not possible in Silverlight.
Read this post: http://forums.silverlight.net/forums/p/12015/38635.aspx
Hope this helped!
Your code is being executed on the UI thread (the same thread that updates the screen). Hence, when you perform any computationally intensive operations your UI will freeze. Long running operations have to run in a separate thread in order for the application to remain responsive. Start a new thread and from within your thread iterate through your loop and instantiate your objects. To add the objects to the canvas you will have to use a Dispatcher to ensure that part of code runs on the UI thread.
MyElement element = new MyElement();
Dispatcher.BeginInvoke(() => AddElementToCanvas(element));
In case a screen of a WPF application contains lots of primitive controls, its rendering becomes sluggish. What are the recommended ways to improve the responsiveness of a WPF application in such a case, apart from adding fewer controls and using more powerful videocard?
Is there a way to somehow use offscreen buffering or something like that?
Our team was faced with problems of rendering performance. In our case we have about 400 transport units and we should render chart of every unit with a lot of details (text labels, special marks, different geometries etc.).
In first our implementations we splitted each chart into primitives and composed whole unit's chart via Binding. It was very sad expirience. UI reaction was extremely slow.
So we decided to create one UI element per each unit, and render chart with DrawingContext. Although this was much better in performance aspect, we spent about one month improving rendering.
Some advices:
Cache everything. Brushes, Colors, Geometries, Formatted Texts, Glyphs. (For example we have two classes: RenderTools and TextCache. Rendering process of each unit addresses to shared instance of both classes. So if two charts have the same text, its preparation is executed just once.)
Freeze Freezable, if you are planning to use it for a long time. Especially geometries. Complex unfreezed geometries execute HitTest extremely slow.
Choose the fastest ways of rendering of each primitive. For example, there is about 6 ways of text rendering, but the fastest is DrawingContext.DrawGlyphs.
Use profiler to discover hot spots. For example, in our project we had geometries cache and rendered appropriate of them on demand. It seemed to be, that no improvements are possible. But one day we thought what if we will render geometries one time and cache ready visuals? In our case such approach happened acceptable. Our unit's chart has just several states. When data of chart is changed, we rebuild DrawingVisual for each state and put them into cache.
Of course, this way needs some investments, it's dull and boring work, but result is awesome.
By the way: when we turned on WPF caching option (you could find link in answers), our app hung up.
I've had the same perf issue with a heavily customized datagrid since one year, and My conclusion is:
there is basically nothing you can do
on your side (without affecting your
app, i.e.: having fewer controls or
using only default styles)
The link mentioned by Jens is great but useless in your case.
The "Optimizing WPF Application Performance" link provided by NVM is almost equally useless in my experience: it just appeals to common sense and I am confident you won't learn anything extraordinary either reading. Except one thing maybe: I must say this link taught me to put as much as I can in my app's resources. Because WPF does not reinstanciate anything you put in resource, it simply reuses the same resource over and over. So put as much as you can in there (styles, brushes, templates, fonts...)
all in all, there is simply no way to make things go faster in WPF just by checking an option or turning off an other. You can just pray MS rework their rendering layer in the near future to optimize it and in the meantime, try to reduce your need for effects, customized controls and so on...
Have a look at the new (.NET 4.0) caching option. (See here.)
I have met a similar problem and want to share my thoughts and founds. The original problem is caused by a virtualized list box that displays about 25 complex controls (a grid with a text block and a few buttons inside displaying some paths )
To research the issue I used the VisualStudio Application Timeline that allows to how much time it takes to render each control and PerfView to find out what actually WPF is doing to render each control.
By default it took about 12ms to render each item. It is rather long if you need to update the list dynamically.
It is difficult to use PerfView to analyse what heppens inside since WPF renders item in the parent-child hierarchy, but I got the common understanding about internall processes.
WPF does following to render each item in the list:
Parse template using XAML reader. As far as I can see the XAML parsing is the biggest issue.
Apply styles
Apply bindings
It does not take a lot of time to apply styles and bindings.
I did following to improve performance:
Each button has its own template and it takes a lot of time to render it. I replaced Buttons with Borders. It takes about 4-5ms to render each item after that.
Move all element settings to styles. About 3ms.
Create a custom item control with a single grid in the template. I create all child elements in code and apply styles using TryFindResources method. About 2ms in the result.
After all these changes, performance looks fine but still most time is spent on loding the ListControl.Item template and the custom control template.
4. The last step: replace a ListControl with Canvas and Scrollbar controls. Now all items are created at runtime and position is calculated manually using the MeasureOverride and ArrangeOverride methods. Now it takes <1ms to render each item from which 0.5ms is spent on TextBlock rendering.
I still use styles and bindings since they do not affect performance a lot when data is changed. You can imagine that this is not a WPF solution. But I fave a few similar lists in the application and it is possible not to use templates at all.
I have a WinForms data entry form that will have upwards of 1500 questions. I have the questions broken into sections, and each section will have an unkown number of questions. Each section is its own user control and has rows (2 panels, 2 labels, a textbox, and another user control) created and added dynamically for each question. The section controls are then added to the form.
My problem is that the process takes a lot of time, even with using TPL (Task Parallel Library). I would ultimately like to create/add the controls and allow the user to start entering data at the same time. The controls are going into a scrollable panel. While the user is entering data, that data will need processed on a local database...so more threading could be necessary.
I have tried working with TPL, which I am new to, by having all the controls added to a list during processing and then sorted and added to the form after the Parallel.ForEach was complete...takes about 20 seconds for over 1200 questions.
I also tried utilizing a BackgroundWorker component. Using the BWC seems to be the faster of the two, but there is a race condition for the ProgressChanged() eventhandler and not all controls get added...not to mention the way the form looks with all the rerendering.
Am i just using TPL wrong? What's the best way to go about this? Is there another way or do I just make the user stick out the wait?
Thanks
Am i just using TPL wrong? What's the best way to go about this? Is there another way or do I just make the user stick out the wait?
Most likely, you can use TPL, and get the same response time as BW, but a nicer API for this type of operation.
The trick here is to get a TaskScheduler setup for UI interaction, and then use the Task class to push the controls back onto the UI thread as they're ready. I have a blog post on this specific subject which shows how to get a TaskScheduler setup to use with UI threads.
However, I would recommend keeping these in memory and pushing them in batches, to avoid constantly re-rendering the UI. This is likely to be an issue no matter what you're doing.
That being said - I'd question your overall visual design here - if you're trying to display over 1200 questions to the user, some form of paging is probably a much nicer approach than a huge scrollable container. If you page these, you could load and process the first few (which is probably near instantaneous, since you mentioned you can process about 50 questions/second), and then continue loading the others after the first few questions have been displayed.