StylusPlugIn OnStylusDown/Move/Up invoked on UI thread and called out of order

[lindexi]

Description

• StylusPlugIn.OnStylusDown / OnStylusUp are sometimes invoked out of order: I see OnStylusUp called on the UI thread, then later OnStylusDown called on the Stylus (pen/touch) thread.

• The incoming message is a touch (StylusDeviceId != 0, e.g. 123), so it should not be handled as a mouse message on the UI thread.

Reproduction Steps

How to reproduce (minimal)

1. Create a class inheriting StylusPlugIn and override OnStylusDown, OnStylusMove, OnStylusUp.
2. Add Thread.Sleep calls inside these methods to simulate expensive work.
3. Rapid multi-finger taps on a touch screen. And set the DPI to 300%
4. Observe that OnStylusUp (UI thread) can be called before OnStylusDown (stylus thread) for the same StylusDeviceId.

I put a minimal repro/demo on GitHub: https://github.com/lindexi/lindexi_gd/tree/107caecee7f847355d23744bf6fc7b970d5e8c69/WPFDemo/LoqairjaniferNudalcefinay

Expected behavior

Events for a given touch/stylus input should be delivered in order and handled on the correct thread for that input type (touch/pen events on the stylus/pen input thread or otherwise consistently marshalled), not processed as mouse/UI-thread messages if StylusDeviceId indicates a touch/pen device.

Actual behavior

OnStylusUp invoked on the UI thread (before OnStylusDown), then OnStylusDown invoked later on the stylus thread. This produces incorrect ordering and state corruption in StylusPlugIn implementations.

Regression?

No response

Known Workarounds

No response

Impact

No response

Configuration

No response

Other information

In WispLogic.cs there is a comment: "We are on the pen thread, just call directly." This is misleading/wrong in context — that line is inside VerifyStylusPlugInCollectionTarget.

wpf/src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Input/Stylus/Wisp/WispLogic.cs

Line 2741 in 348310e

// We are on the pen thread, just call directly.

VerifyStylusPlugInCollectionTarget is only called from WispLogic.PreNotifyInput, and PreNotifyInput is wired to InputManager.PreNotifyInput: _inputManager.Value.PreNotifyInput += new NotifyInputEventHandler(PreNotifyInput); . InputManager.PreNotifyInput is raised on the UI thread, so the code path does not guarantee we are on the Stylus Input thread.

Because targetPIC.FireRawStylusInput in VerifyStylusPlugInCollectionTarget assumes "Stylus Input thread", StylusPlugIn callbacks can be invoked on the UI thread incorrectly.

[lindexi]

Why the Stylus Down raise in UI thread?

Because the Stylus Input thread can not get the stylusDevice.CriticalActiveSource randomly, as the image shows:

When the stylusDevice.CriticalActiveSource be null, the Point ptTablet can not be converted to WPF coordinate system, and it means that the point never calculate the DPI scale. That will cause the StylusPlugIn miss hit and the StylusPlugInCollection pic be null.

The Stylus Input thread will miss call the StylusPlugInCollection when PenContexts.TargetPlugInCollection return null. Because the Stylus Input thread do not call the StylusPlugInCollection, the PenContexts.InvokeStylusPluginCollection do not enter the if (pic != null) branch, and the rawStylusInputReport.RawStylusInput will be null:

wpf/src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Input/Stylus/Wisp/PenContexts.cs

Lines 432 to 443 in 348310e

	if (pic != null)
	{
	// NOTE: PenContext info will not change (it gets rebuilt instead so keeping ref is fine)
	// The transformTabletToView matrix and plugincollection rects though can change based
	// off of layout events which is why we need to lock this.
	GeneralTransformGroup transformTabletToView = new GeneralTransformGroup();
	transformTabletToView.Children.Add(new MatrixTransform(_stylusLogic.GetTabletToViewTransform(inputReport.InputSource, stylusDevice.TabletDevice))); // this gives matrix in measured units (not device)
	transformTabletToView.Children.Add(pic.ViewToElement); // Make it relative to the element.
	transformTabletToView.Freeze(); // Must be frozen for multi-threaded access.
	RawStylusInput rawStylusInput = new RawStylusInput(inputReport, transformTabletToView, pic);
	inputReport.RawStylusInput = rawStylusInput;

When the rawStylusInputReport.RawStylusInput be null, the UI thread will invoke the StylusPlugIn:

wpf/src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Input/Stylus/Wisp/WispLogic.cs

Line 2691 in 348310e

if (targetPIC != null && rawStylusInputReport.RawStylusInput == null)

---

Why the stylusDevice.CriticalActiveSource be null? Let's look the CriticalActiveSource property:

wpf/src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Input/Stylus/Wisp/WispStylusDevice.cs

Line 139 in 348310e

internal override PresentationSource CriticalActiveSource => _inputSource;

Oh, the CriticalActiveSource only return the _inputSource field. And the _inputSource field only be set init in WispStylusDevice.UpdateState and WispStylusDevice.UpdateStateForSystemGesture. Both WispStylusDevice.UpdateState and WispStylusDevice.UpdateStateForSystemGesture only call in UI thread, which means the Stylus Input thread may get the Uninitialized _inputSource field and the stylusDevice.CriticalActiveSource be null.

---

The interesting thing is the inputReport argument contain the right HwndSource. And I think we do not need to use stylusDevice.CriticalActiveSource here, and we can directly use the inputReport.InputSource.

wpf/src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Input/Stylus/Wisp/PenContexts.cs

Line 460 in 348310e

internal StylusPlugInCollection TargetPlugInCollection(RawStylusInputReport inputReport)

And the RawStylusInputReport inputReport be created in ProcessInput method, and the ProcessInput method mush pass the PresentationSource inputSource to RawStylusInputReport. I think it means that using the inputReport.InputSource property in TargetPlugInCollection method will be correct.

[D1firehail]

I've also encountered this issue, here are some observations I've made:

• The Timestamp provided by RawStylusInput can be used to notice this happening to separate calls to OnStylusMove.
• I used Thread.CurrentThread.ManagedThreadId to notice the thread inconsistency, and it being connected to the order inconsistency.
• Using OnStylusMoveProcessed (transferring data via RawStylusInput.NotifyWhenProcessed) doesn't seem to suffer from any out-of-order issues.

[lindexi]

@D1firehail Thank you.

Why Using OnStylusMoveProcessed (transferring data via RawStylusInput.NotifyWhenProcessed) doesn't seem to suffer from any out-of-order issues. ?

Because all the NotifyWhenProcessed will work in the UI thread.