Hi,
We are implementing a drag and drop feature on an item control that contains complex UI elements.
When the number of UI elements increases, we see the frame-rate dropping considerably during the drag action.
After profiling the application, we see that what takes time is the GetElementsUnderMouse method (and inside it, the HitTestPointNegative method). Oddly, the cpu doesn't jump to the roof, it's just the framerate that drops below 10 per seconds!
Another related problem that might give an insight is that we use RadWindow a lot in our app. Apparently, the GetElementUnderMouse will get ALL the elements under the mouse, through the windows and anything else in the vidsual tree. This means that if we have 2 windows overlapping, the GetElementUnderMouse method is also getting the element that are behind the top window, which is really a big waste.
Is there any obvious way for us to get around this big performance problem? Of course reducing the number of UIElements in our controls seems the first approach to consider for us. What else could possibly cause such a behaviour?
Attached is a screenshot of the trace while dragging an element over our items control for a few seconds.
Stephane
We are implementing a drag and drop feature on an item control that contains complex UI elements.
When the number of UI elements increases, we see the frame-rate dropping considerably during the drag action.
After profiling the application, we see that what takes time is the GetElementsUnderMouse method (and inside it, the HitTestPointNegative method). Oddly, the cpu doesn't jump to the roof, it's just the framerate that drops below 10 per seconds!
Another related problem that might give an insight is that we use RadWindow a lot in our app. Apparently, the GetElementUnderMouse will get ALL the elements under the mouse, through the windows and anything else in the vidsual tree. This means that if we have 2 windows overlapping, the GetElementUnderMouse method is also getting the element that are behind the top window, which is really a big waste.
Is there any obvious way for us to get around this big performance problem? Of course reducing the number of UIElements in our controls seems the first approach to consider for us. What else could possibly cause such a behaviour?
Attached is a screenshot of the trace while dragging an element over our items control for a few seconds.
Stephane
3 Answers, 1 is accepted
0
stephane
Top achievements
Rank 1
Rank 1
answered on 31 Jan 2011, 04:28 PM
We found that if we set IsHitTestVisible on the elements that we don't care about, then it becomes fluid again.
So as a temporary solution we will probably try to set IsHitTestVisible to false where it makes sense when we begin to drag an element.
Maybe that will give you optimization ideas on your side?
If you have any other/better solution, I will keep following this thread.
So as a temporary solution we will probably try to set IsHitTestVisible to false where it makes sense when we begin to drag an element.
Maybe that will give you optimization ideas on your side?
If you have any other/better solution, I will keep following this thread.
0
Accepted
Hi stephane,
Currently, we hittest in depth of 100 UIElements. As this cannot be altered with the current version, we would consider exposing properties for controlling the maximum elements being tested.
All the best,
Tsvyatko
the Telerik team
Currently, we hittest in depth of 100 UIElements. As this cannot be altered with the current version, we would consider exposing properties for controlling the maximum elements being tested.
All the best,
Tsvyatko
the Telerik team
Let us know about your Windows Phone 7 application built with RadControls and we will help you promote it. Learn more>>
0
stephane
Top achievements
Rank 1
Rank 1
answered on 04 Mar 2011, 10:47 AM
We are setting IsHitTestVisible to false on a lot of elements when starting dragging, and resetting it to true when the drag action is completed. This solves our issue, but is not very elegant.
In most of the case the depth doesn't need to be more that 5 or 10 elements (as we see it).
Making the depth configurable would be even nicer, of course.
Stephane
In most of the case the depth doesn't need to be more that 5 or 10 elements (as we see it).
Making the depth configurable would be even nicer, of course.
Stephane