You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I discovered that the implementation of PointerTouchDevice uses a particularly strange and incorrect method to obtain the size of the touch point. In the GetStylusPointWidthOrHeight method of PointerTouchDevice, it attempts to extract the width and height information of the touch point. However, it uses Resolution for conversion, thus obtaining the physical size of the touch point. Please pay special attention to this point: the physical size of the actual touch is obtained here. Subsequently, the physical size of the actual touch is used in calculations with pixelsPerInch. However, this pixelsPerInch represents the screen DPI value of the display, which cannot be associated with the physical size of the actual touch. This leads to a very strange and incorrect touch size being returned in PointerTouchDevice. The core issue is the confusion between the screen DPI and the physical size of the touch.
The code of main issues are value /= propertyInfo.Resolution; and value *= pixelsPerInch;.
What is Correct Behavior?
There are two aspects to consider:
Providing True Physical Dimensions: To obtain the true physical dimensions, use the following code: value /= propertyInfo.Resolution;. This computation delivers the real-world physical size.
Returning Pixel Dimensions: If the goal is to return the pixel dimensions, you need to acquire the maximum and minimum values of StylusPointProperty and calculate the ratio against the screen dimensions. By doing this, you can determine the touch size in terms of the screen resolution. Subsequently, you can incorporate the DPI to translate this size into pixel dimensions within the WPF coordinate system.
I do not think it is the design issues. But some one may dependent on this behavior to build the application.
The text was updated successfully, but these errors were encountered:
That code seems to be used for the touch point bounding rectangle, which seems to be reasonable to be in pixels? You don't mention what you expect the behavior to be.
I discovered that the implementation of
PointerTouchDevice
uses a particularly strange and incorrect method to obtain the size of the touch point. In theGetStylusPointWidthOrHeight
method ofPointerTouchDevice
, it attempts to extract the width and height information of the touch point. However, it usesResolution
for conversion, thus obtaining the physical size of the touch point. Please pay special attention to this point: the physical size of the actual touch is obtained here. Subsequently, the physical size of the actual touch is used in calculations withpixelsPerInch
. However, thispixelsPerInch
represents the screen DPI value of the display, which cannot be associated with the physical size of the actual touch. This leads to a very strange and incorrect touch size being returned inPointerTouchDevice
. The core issue is the confusion between the screen DPI and the physical size of the touch.wpf/src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Input/Stylus/Pointer/PointerTouchDevice.cs
Lines 77 to 119 in 9e2995f
The code of main issues are
value /= propertyInfo.Resolution;
andvalue *= pixelsPerInch;
.What is Correct Behavior?
There are two aspects to consider:
Providing True Physical Dimensions: To obtain the true physical dimensions, use the following code:
value /= propertyInfo.Resolution;
. This computation delivers the real-world physical size.Returning Pixel Dimensions: If the goal is to return the pixel dimensions, you need to acquire the maximum and minimum values of
StylusPointProperty
and calculate the ratio against the screen dimensions. By doing this, you can determine the touch size in terms of the screen resolution. Subsequently, you can incorporate the DPI to translate this size into pixel dimensions within the WPF coordinate system.I do not think it is the design issues. But some one may dependent on this behavior to build the application.
The text was updated successfully, but these errors were encountered: