Our application starts up with several docked RadPanes, each of which presents the FrameWorkElement from a WPF UserControl. In those UserControl FrameWorkElements which make extensive use of data binding, sometimes in support of MVVM pattern, we note significant CPU usage and an unresponsive UI during the transition between RadPane (docked) to ToolWindow (floating). It appears that the greater the amount of data binding, the longer the UI is unresponsive.
What I think is happening: when a RadPane transitions between the RadSplitContainer and ToolWindow there is a change in the DataContext for that RadPane such that all the UI elements are notified and the Main Thread gets buried running Event Handlers supporting the data bindings.
Does that sound plausible?
If so, during the transition from Dock to Float, I would like to instrument our code at the points where the containers are instantiated to further my understanding of what is happening. Is there an Event to which I can subscribe when a RadPane is docked or floated?
On floating, would it be possible to, for example, defer the rendering of the FrameWorkElement until maybe a MouseUp or DraggingComplete event occurs?
Is there a way to transfer the same UserControl FrameWorkElement object between the RadPane and ToolWindow to avoid the data binding?
Thanks in advance for your input. This is a bit of a show stopper issue at the moment!
What I think is happening: when a RadPane transitions between the RadSplitContainer and ToolWindow there is a change in the DataContext for that RadPane such that all the UI elements are notified and the Main Thread gets buried running Event Handlers supporting the data bindings.
Does that sound plausible?
If so, during the transition from Dock to Float, I would like to instrument our code at the points where the containers are instantiated to further my understanding of what is happening. Is there an Event to which I can subscribe when a RadPane is docked or floated?
On floating, would it be possible to, for example, defer the rendering of the FrameWorkElement until maybe a MouseUp or DraggingComplete event occurs?
Is there a way to transfer the same UserControl FrameWorkElement object between the RadPane and ToolWindow to avoid the data binding?
Thanks in advance for your input. This is a bit of a show stopper issue at the moment!
3 Answers, 1 is accepted
0
Mike5
Top achievements
Rank 1
Rank 1
answered on 19 Apr 2013, 04:21 PM
My thought at this point is to override RadDocking.OpenInToolWindow() when the user first floats the RadPane. My override would change the present functionality of transferring the container to the newly created ToolWindow to caching the container object in a new static class and creating and empty, lightweight placeholder container to fill the ToolWindow. In the scenario where the ToolWindow is then docked, override RadDocking.OnDropContainer() to restore that cached container. This seems feasible based on initial prototype test. The rendering of the new ToolWindow with the placeholder container is much faster on my I5 machine. Something similar when the ToolWindow is left floating... override the EventHandler that fires when dragging stops.
0
Hello,
We are not aware of any performance issues when switching Panes from docked to floating state but you should note that when a Pane is made floating it is removed from the visual tree and then placed in a ToolWindow which could cause some performance issues if the Pane's content is binding or UI heavy.
The previously described approach on lightweight containers seems that it should hep that scenario but we cannot provide you with a sample project of that approach.
Kind regards,
Vladi
the Telerik team
We are not aware of any performance issues when switching Panes from docked to floating state but you should note that when a Pane is made floating it is removed from the visual tree and then placed in a ToolWindow which could cause some performance issues if the Pane's content is binding or UI heavy.
The previously described approach on lightweight containers seems that it should hep that scenario but we cannot provide you with a sample project of that approach.
Kind regards,
Vladi
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
0
Mike5
Top achievements
Rank 1
Rank 1
answered on 24 Apr 2013, 09:03 PM
Hello Vladi,
Thank you for your response. Yes, I think when the UIElement is placed in the new floating ToolWindow or at a compass docking target, the delay I see is the databinding, calculation of Auto sizes, etc. associated with the UIElement. It's a scaling issue, I would say, in that it does not scale! If I could avoid removing and re-adding the UIElement to the Visual Tree when floating/docking, I expect the delay would go away. For now, a lightweight placeholder snapshot of the contents of the Pane... and a faster CPU.
Regards,
Mike5
Thank you for your response. Yes, I think when the UIElement is placed in the new floating ToolWindow or at a compass docking target, the delay I see is the databinding, calculation of Auto sizes, etc. associated with the UIElement. It's a scaling issue, I would say, in that it does not scale! If I could avoid removing and re-adding the UIElement to the Visual Tree when floating/docking, I expect the delay would go away. For now, a lightweight placeholder snapshot of the contents of the Pane... and a faster CPU.
Regards,
Mike5