Performance problem - blocking of dispacher thread

Grids for WPF Forum

Posted 8 years ago by Zbynek Vrastil
Version: 11.2.0553
Avatar

Hello,

we're using PropertyGrid (version 11.1.0545.1) within pure-WPF application that shows live video (live image from electron microscope in our case). Live video is done through Image & WriteableBitmap. WriteableBitmap back buffer is filled in on background thread. However, due to WPF limitations, WriteableBitmap has to be locked and unlocked on Dispatcher thread. This means that when Dispatcher thread is blocked for longer than frequency of video update, video image visibly staggers. Simply put, we have strict requirement on maximal time spent within one dispatch of Dispatcher thread.

That's where PropertyGrid comes in. Typical object set to PropertyGrid.SelectedObjects (some graphics on top of video image) has two categories (basic & advanced), one with 8 and second with 30 properties. Setting such object to PropertyGrid always cause video to stagger - PropertyGrid simply takes too much time to build its UI. When categories are initially collapsed, video staggers at the moment of expanding Advanced category (the one with 30 properties).

Is there any way to improve this user experience? I understand most of the work has to be done on Dispatcher thread - but maybe there's some way to divide work between multiple dispatches (so video update can take time in between)? Or do you have any other suggestion how to solve it? Are there any guidelines how to make property grid update as fast as possible? For example, can it be somehow "pre-built" and then just filled with values of particular object instance?

thanks for any help,

Zbynek Vrastil

Comments (5)

Answer - Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Zbynek,

We have a topic in our documentation that outlines the steps you can take to get the most performance out of the PropertyGrid, which includes enabling virtualization (which may not help if all the properties are visible). Unfortunately, aside from what is outlined in that topic we don't have any other optimizations available at this time.


Actipro Software Support

Posted 8 years ago by Zbynek Vrastil
Avatar

Hello,

thanks for your reply. In the meantime, I tried following approach - instead of providing SelectedObjects, I fill in property grid "manually" through its Items property. To prevent Dispatcher thread starving, every item is added on separate BeginInvoke with Background priority. This works quite well - video is alive and property grid is visibly filled item-by-item. There's one problem still - PropertyGrid.Items.Clear() seems quite slow and it staggers video stream on its own.

I've seen similar behavior even when using SelectedObjects - setting it to empty collection takes quite a long time. Consider following use-cases:

1) property grid is empty, set SelectedObjects to an object (no clear needed as grid is empty) - takes time T1

2) property grid is not empty, set SelectedObjects to empty collection (just clear) - takes time T2 = cca 3*T1

3) property grid is not empty, set SelectedObjects to an object (clear needed, grid is not empty) - takes time T3 = cca T1+T2

I measured times on SelectedObjects setter using WinAPI High Performance Counter.

Can you confirm this? If yes, can you please investigate why clearing property grid takes more time than filling it in? Measured on version 11.1.0545.1.

thanks, Zbynek

Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Zbynek,

I'm not seeing any delay when clearing the Items collection or setting SelectedObject(s) to null. But you may try setting PropertyGrid.IsAsynchronous to false, as this will prevent the PropertyGrid from generating the data items on a separate thread (which then need to be dispatched back into the UI thread for display).

If that doesn't help please put together a small sample project that reproduces your issue and email it over then we can take a closer look. Be sure to remove any executables or change the extension of the zip file to ensure it gets past our email filters.


Actipro Software Support

Posted 8 years ago by Zbynek Vrastil
Avatar

I've sent small sample project to show this behavior to support@actiprosoftware.com.

Zbynek

Answer - Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Zybnek,

Thank you for the sample application. The timing code in your sample isn't really capturing all that is going on for each operation. While you do have IsAsynchronous="False", there are still some things that are resolved/executed later (all of which is built into WPF as a function of any ItemsControl). The IsAsynchronous only determines whether we will generate the properties on a separate thread, then set the PropertyGrid.ItemsSource. Which is the same regardless of whether you are setting the SelectedObject to an object or null.

Regardless of what you set SelectedObject to, we are simply turning around and setting the ItemsSource to either a collection of properties or null. WPF will then take over and perform normal ItemsControl type container generation and layout (arrange & measure) when it sees fit.

It appears in the case of setting it to null, more work is being performed at that time (instead of being delayed). You can get more accurate times by adding "propertyGrid.UpdateLayout();" after you set SelectedObject in your three button click handlers. This forces WPF to execute everything it may have delayed immediately.

Once you add that, you will see that the total amount of work performed is actually more when you are setting SelectedObject (and thus ItemsSource) to a non-null value.


Actipro Software Support

The latest build of this product (v2019.1 build 0683) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.