In our usage of RadDiagram, we enable our shapes to be positioned with subpixel accuracy. However, we notice that the AdornerManipulator for our shapes is always a little bit larger and aligned exactly on pixel borders. For instance, if have a diagram shape positioned at 20,30.5, the adorner will be positioned at 20,30. If that same shape is 40x50 pixels, the bottom of the adorner will be at 60,31.
I think I found the code that does this in RadDiagram.UpdateManipulationAdorner; that code taking the Math.Floor of the position and the Math.Ceiling of the extents. This makes the adorner lie exactly on a pixel but also makes it not match the adorned object.
This seems like surprising behavior to me; the manipulation-adorner ends up being not quite the bounds of the object adorned. However, it also looks like someone pretty intentionally put code in place for this behavior.
We are on the 2013.3.1204 release; I don't think any of the release notes since then mention changes related to this functionality.
1) Is this a correct evaluation of what's happening?
2) What considerations led to the decision that the AdornerManipulator has this behavior? What negative side effects might we expect if we were to remove the Ceiling and Floor calls and instead use the exact position and extents?
3) While we can certainly modify this behavior locally, is this something that you all would address in a future release, please?
Thank you!
-David
I think I found the code that does this in RadDiagram.UpdateManipulationAdorner; that code taking the Math.Floor of the position and the Math.Ceiling of the extents. This makes the adorner lie exactly on a pixel but also makes it not match the adorned object.
This seems like surprising behavior to me; the manipulation-adorner ends up being not quite the bounds of the object adorned. However, it also looks like someone pretty intentionally put code in place for this behavior.
We are on the 2013.3.1204 release; I don't think any of the release notes since then mention changes related to this functionality.
1) Is this a correct evaluation of what's happening?
2) What considerations led to the decision that the AdornerManipulator has this behavior? What negative side effects might we expect if we were to remove the Ceiling and Floor calls and instead use the exact position and extents?
3) While we can certainly modify this behavior locally, is this something that you all would address in a future release, please?
Thank you!
-David
1 Answer, 1 is accepted
0
Accepted
Hello David,
We checked the code in the UpdateManipulationAdorner methods. We can confirm the purpose of the Floor() and Ceiling() roundings you mentioned is to resolve blurring issues. These issues cannot be easily solved with UseLayoutRounding or SnapsToDevicePixels properties that come directly from the WPF Framework.
You can log a feature request in our feedback portal and you can describe in it the scenario you need to be supported. Later we can approve it and if it gathers enough votes we will consider implementing it.
Regards,
Petar Mladenov
Telerik
We checked the code in the UpdateManipulationAdorner methods. We can confirm the purpose of the Floor() and Ceiling() roundings you mentioned is to resolve blurring issues. These issues cannot be easily solved with UseLayoutRounding or SnapsToDevicePixels properties that come directly from the WPF Framework.
You can log a feature request in our feedback portal and you can describe in it the scenario you need to be supported. Later we can approve it and if it gathers enough votes we will consider implementing it.
Regards,
Petar Mladenov
Telerik
Check out Telerik Analytics, the service which allows developers to discover app usage patterns, analyze user data, log exceptions, solve problems and profile application performance at run time. Watch the videos and start improving your app based on facts, not hunches.