Performance problem - blocking of dispacher thread

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.

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

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.

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

Zbynek

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.