Ignoring MouseMoveEx errors and fall back to passed point. #883
Conversation
MouseMoveEx can return e.g. an "access denied" error, in this case it is sensible to return to fall back to the old mouse move handling. Fixes issues like opentk#820
|
Hi Christoph, thanks so much for wanting to contribute to OpenTK! It's people like you that keep the project going. Unfortunately, this PR isn't feasible with the direction we're taking OpenTK in 4.0, as we're completely removing the native platforms. That means that we're deleting the code for Win32, SDL, and X11 altogether. If you want to learn more about 4.0, I advise looking at #867 #805 #823 or join our Discord server! |
|
Hi Dylan, thank you for your quick reply. Should I change the pull request to base on the 3.0 branch, or will there be no more bugfix releases for the 3.0 line? Regards |
|
Unfortunately, we've frozen the 3.0 branch to focus all our efforts to 4.0, so PRs to that branch will be rejected. It will help us concentrate on 4.0 though - the biggest update since 2006 - so there is good reason behind this decision. |
|
Ok, I was just trying to push the fix upstream in case other people run into it. I am looking forward to migrating to 4.0, good luck with the new version. |
|
Thanks! We look forward to get it in your hands :) |
|
@varon Candidate for the 3.0 final release. Have a look over it if you find yourself with nothing to do? |
|
Changes will need to be rebased onto 3.0 as this currently targets 4.0 |
opentk/opentk#914 opentk/opentk#883 Primarily bumping for these two, SharpcCompress contains various non-critical fixes.
|
@leezer3 - About to do re-do this PR, but figure it's a good enough place to contact you as I don't see you on the Discord. Anything fixes or minor stuff you'd like to get in for the next 3.x update? |
|
Nothing I know about a fix for. IIRC there's a (minor) problem somewhere with the SDL2 backend on Linux when in windowed mode, think it was related to mouse co-ordinates / grabbing when outside the window. |
|
We might also want to consider these: Untested here, & some may have come in through tyronx's PR you've just merged. |
|
Another one from @tyronx which I don't believe has been merged: Do we want a tracker issue with the outstanding stuff for 3.1 on? n.b. Not on Discord or most other social media, chat etc, sorry :P |
|
Didn't seem to have been, although I only skimmed the diff :) |
|
Another one which is potentially implementable for very little work: The code in the first post of the issue looks highly sensible to me. |
|
Yea no, #758 is already merged @leezer3 -> https://github.com/opentk/opentk/pull/914/files#diff-694ec1e1f131287c58c05ce3f7bbce1dR73 |
|
Is there anything I can do here to help with my original pull request? |
|
You should be fine- I've included it in #935 Should hopefully be merged into 3.0 soon. |
|
Thanks so much @ChristophHornung and @leezer3. Hugely appreciated this. Closing this PR, as this fix was introduced in #935 . Please do come join our very active community on Discord! |
frederikja163
changed the title
GetMouseMovePointsEx can return e.g. an "access denied" error, in this case it is sensible to return to fall back to the old mouse move handling.
Fixes issues like #820
Purpose of this PR
Description: GetMouseMovePointsEx was introduced in 095d3f2 and added Win32Exceptions that were thrown on all errors except "ERROR_POINT_NOT_FOUND". Other errors can be returned from GetMouseMovePointsEx such as "Access denied" (see: #820)
Affects: WinGl
Testing status
A custom version of OpenTK with the error ignored and previous point handling being used was installed for affected users, the error did not occur again over the span of a few weeks. Rolling back to the base version did reintroduce the error.
Comments
I am still uncertain about the root cause of the error. Microsoft's documentation does not mention why the error would be returned and since the error was not reproducible on most machines (including all of mine) it was hard to guess a root cause. Some users did mention this occurred mostly after leaving the program idle for a few minutes, some reported it to occur after awaking the computer from a screensaver state. The users that did see the error had mostly older hardware.
Since GetMouseMovePointsEx is only used for smoothing out mouse movements I feel it is acceptable to ignore this error, the only thing "going wrong" in this case is the missing smooth, which already is done in case of the ERROR_POINT_NOT_FOUND error.