Hit test fails if mouse is over a text object

[vsfeedback]

Hello Microsoft Support,

I've drawn a text by a DrawingVisual object, but the hit test fails when the mouse pointer is on it. For hit testing I'm using a GeometryHitTestParameters and EllipseGeometry objects. I've notice that if I use a PointHitTestParameters object, so all works well.

I've attached a complete solution that show the problem. Let me point out, that this issue is very serious for us because it doesn't allows to go on in our work.
Thank you in advance.
Best regards,

Simone

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/533445/hit-test-fails-if-mouse-is-over-a-text-object.html
VSTS ticketId: 847713
These are the original issue comments:

Visual Studio Feedback System on 4/15/2019, 07:36 PM (17 days ago):

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Jeff Schwartz [MSFT] on 4/16/2019, 04:20 PM (16 days ago):

Thanks for sharing feedback @Simone Padovan. Can you elaborate more on what is not happening that you would expect?

In the attached sample I am seeing the proper events fire and callbacks fire (by setting break points and mousing over the text block). Thanks

Jeff Schwartz [MSFT] on 4/17/2019, 02:49 PM (15 days ago):

Thanks for the details. I am going to route to the WPF team.

These are the original issue solutions:

Simone Padovan solved on 4/17/2019, 10:14 AM (16 days ago), 0 votes:

Hello Jeff,

thank you for the answer. Sorry, I was unclear. Actually the HitTestCallback is called, because it is a consequence of the VisualTreeHelper.HitTest (RenderingHost.cs file line 34) method call from the mouse move event handler. But the interesting point is that the found object isn't the DrawingVisual of the text but it is the RenderingHost parent. The evidence is that you aren't able to see the "Entity found !!" message box. This occurs because the VisualTreeHelper.HitTest is called by passing a GeometryHitTestParameters as fourth parameter. Instead if you use a PointHitTestParameters you will see the message. The code is ready: simply comment/uncomment the 33 and 34 lines in the RenderingHost.cs file. Let me point out, that this issue is linked to the matrix transform at line 34 in the MainWindow.xaml.cs file: in fact if you comment it and the 37 line, the text is recognized and you will see the "Entity found !!" message box.

I think that this issue is linked to my other bug report The PathGeometry filling fails… just that the point is the area painting but the problem source is the matrix: It would be great if you solve two problems at once.

Thank you in advance.

Regards,

Simone

[Simon-IT]

This was my reporting. After further investigation, the problem is not related to a text object but to all geometries where more than one transformation is applied to it. In the hit testing by geometry algotithm, the order in which the transformations are crosses is wrong. I've attached a VS solution that show better the problem: simply compile and test the project with and without the APPLY_TWO_SEPARATED_TRANSFORMATIONS conditional compilation symbol. Move the mouse over the text and/or circle. I'll open a pull request with my changes.

HitTestringByGeometryFails.zip

[weltkante]

@grubioe can we get that reclassified and not put on 'future'? Its a genuine framework bug and the PR basically solved the problem already.

The problem is that when you push multiple matrix transformations into a DrawingContext the framework in some code paths (i.e. when hit testing) evaluates them in the wrong order.

[Simon-IT]

@grubioe Great!! It would be fantastic if the bug will be resolved into 3.0

[vatsan-madhavan]

3.0 is pretty much finished @Simon-IT.

@grubioe, I like this for 5.0 and as a possible fix for 3.1 as well if it fits within our bug-bar.

[grubioe]

@Simon-IT - can you elaborate more on your business scenario and give us a bit more sense of the impact of this bug? Given that 3.1 is an LTS release the bar is much higher. Thank you.

[weltkante]

Not speaking for the OP, but having looked at the bug (and debugged it) I'll try to describe its impact. The bug is a math error in a very specialized code path composing transformation matrices when hit testing against a DrawingContext, you hit this code path when you have pushed multiple transformation matrices into a DrawingContext. Other code paths (e.g. rendering or plain transformation compositions) do not have this bug, so this hit testing code path differs from all others.

The impact of the bug is that it makes DrawingContext Push operations not composable. If you have a Render override on a Control or are using DrawingVisuals you cannot write modular code to draw into the DrawingContext using Push operations. You usually use Push operations when you have reusable drawing functions, you push the transformation to determine the position and scale of what you are drawing, the drawing code then can be position independent. If you happen to push multiple transformations (i.e. compose multiple such drawing functions) they will trigger this bug and what you have drawn will not be hit-testable.

The workaround is to not use DrawingContext Push operation more than once and instead precomposing all transformations in the callers (keeping your own stack of transformations). You could also write a wrapper around DrawingContext to isolate the workaround, but either way its a very intrusive workaround because you cannot use the WPF API as-is and have to write a replacement.

[Simon-IT]

Hi, @weltkante explained well the problem. In our company, we are rewriting our sppecialized CAD program from WinForms to WPF. Besides using WPF for the UI, we use it for geometry drawing operations too. The graphic engine draws all the geometries into DrawingVisual objects that are children of a user control derived from FrameworkElement. This control has a scale transform with Y = -1 to have Y axis that points up. For every geometry we use a transformation for zoom a pan features but text objects has one more (another Y = -1) to compensate the "mirror" effect. This push two transformations that will be composed into the render pipe. This trigger the bug.
In this regard I wish to recall the oder bug 643 which is perhaps even more important than this. I'll continue the discussion about it at the proper issue page.
Thank you.