change timer for smoother mouse follow

[Boumtchack]

Link to issue number:

Partially addressing #19987

Summary of the issue:

When following the mouse, the NVDA magnifier panned in a jerky, discontinuous way compared to the built-in Windows Magnifier. Users noticed a distinct "pause then jump" instead of smooth real-time panning.

Description of user facing changes:

Mouse panning is now significantly smoother. The magnifier follows the mouse in real time at up to 125 Hz instead of being capped at the system's default timer resolution (~67 Hz).

Description of developer facing changes:

timeBeginPeriod(1) / timeEndPeriod(1) are now called from winmm.dll (via the new winBindings.winmm bindings) when the magnifier starts and stops. The update timer is now a repeating wx.Timer (oneShot=False) rather than a self-rescheduling one-shot timer, removing per-tick object creation overhead. _TIMER_INTERVAL_MS is now 8 ms.

Description of development approach:

The root cause was two-fold: Windows default timer resolution (~15 ms floor) made sub-15 ms intervals ineffective, and the self-rescheduling one-shot pattern added creation overhead at every tick. Setting the timer resolution to 1 ms removes the floor; switching to a repeating timer removes the overhead.

Testing strategy:

updated unit, manual

Known issues with pull request:

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[CyrilleB79]

Thanks for this attempt to tackle #19987.

Unfortunately, panning is still jerky even in this PR, while Windows Magnifier is smooth. I woud not say that it fully closes #19987.

Given we can easily see the mouse move, it's quite clear that we have not 125ms refresh period for mouse tracking.

Can you indicate, maybe in #19987, if you have explored other ideas?

[Boumtchack]

well it doesn't fix the mouse, only the magnified view refresh rate.

I think the mouse issue should be adressed in an other pr. I don't want to had to much code at a time as it seems to slow down the process more than anything

[Boumtchack]

Given we can easily see the mouse move, it's quite clear that we have not 125ms refresh period for mouse tracking.
Can you indicate, maybe in #19987, if you have explored other ideas?

I think the problem here is that I'm not triggering on event but I'm checking status so it's why it's "laggy", changing the logic to event would probably resolve this, I'm working on it

[CyrilleB79]

I think the mouse issue should be adressed in an other pr. I don't want to had to much code at a time as it seems to slow down the process more than anything

Yes, NV Access prefer smaller and well targetted PRs than big ones; as you have noted, this render the process smoother.

Performing improvements one at a time is OK.

You should just modify the initial description "Closes #19987" since "Close" is a GitHub magic word which will trigger #19987 closing.
Since the improvement in this PR is only a part of the work to address #19987 , #19987 should not be closed by this PR. You can for example write: "Partially addressing #19987 ".

[seanbudd]

The issue #19987 was particularly about a change in smoothness due to setting a higher DPI. Is this PR related to the DPI issue? Could you reproduce that one?

[Boumtchack]

This PR targets the general mouse panning jerkiness (as described in #20060), not the DPI-specific lag in #19987. The root cause here is the Windows timer resolution floor (~15ms), which we address with timeBeginPeriod(1). The DPI-specific issue, where lag is significantly worse at 225% scaling vs 100% on the same display, is a separate investigation that we haven't reproduced or addressed yet.

[CyrilleB79]

This PR targets the general mouse panning jerkiness (as described in #20060), not the DPI-specific lag in #19987.

Sorry @Boumtchack, you seem to be mixing things here.

• NVDA Magnifier - Moving the view should be smoother #20060 is about having smoother moves of the magnified view (even if the system text cursor is moved jerkily); and you have even attempted to find a solution in Feature/smoother magnifier #20226 (work stopped for now due to priorisation); by the way, I have added an additional comment to clarify that such smoothening should not apply to mouse moves so that the mouse cursor can remain steady in the center of the screen.
• according to @seanbudd and @Qchristensen, NVDA Magnifier following the mouse lags compared to Windows magnifier #19987 seems to be about a more important jerkiness of magnified view moves when moving the mouse if you use higher Dpi. It's not clear at all from the title nor in the initial description, but that's clarified later in the discussion (e.g. NVDA Magnifier following the mouse lags compared to Windows magnifier #19987 (comment)).
• There is also a general jerkiness issue when moving the mouse which is visible at 100% scaling too: And this PR is meant to improves it (though not fully with respect to Windows Magnifier). FWIK, there is no corresponding issue opend for this.

[Boumtchack]

Yes, I've been looking at the dpi one on an other branch that I will share soon I hope, I have a hard time remembering every scope of every issues and their updates. I'm sorry for that I'm doing my best.

[CyrilleB79]

I'm sorry for that I'm doing my best.

Don't worry, there are a lot of issues and not all are very clearly worded...