New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle Mouse events rather than polling #774

Merged
merged 4 commits into from Jun 1, 2017

Conversation

2 participants
@peppy
Member

peppy commented May 31, 2017

Need people to test this and see how it performs on different operating systems. Also whether it is more or less RAW than previous.

  • Need macOS users to test if this fixes cursor input not working for some devices.
  • Need windows users to test whether this has acceleration or not.
  • Need linux users to test how this works in general.

As I'm currently running windows in a virtualised device, I haven't tested native behaviour yet myself. OpenTK docs suggest using the events gives raw input response, but from my testing so far this doesn't seem correct.

@peppy

This comment has been minimized.

Show comment
Hide comment
@peppy

peppy May 31, 2017

Member

Tested with native mouse on windows, does not bypass acceleration. See #775 for a different attempt.

Member

peppy commented May 31, 2017

Tested with native mouse on windows, does not bypass acceleration. See #775 for a different attempt.

@peppy peppy changed the title from Use events to drive mouse input to Handle Mouse events rather than polling May 31, 2017

@peppy

This comment has been minimized.

Show comment
Hide comment
@peppy

peppy May 31, 2017

Member

Continuing developing this PR as a base implementation (replacement for previous non-raw input polling handler).

Member

peppy commented May 31, 2017

Continuing developing this PR as a base implementation (replacement for previous non-raw input polling handler).

@peppy peppy referenced this pull request May 31, 2017

Merged

Fix mouse handling on linux #761

peppy added some commits May 31, 2017

Clean up state handling
Reverts fix in #761 as it is the incorrect way to fix things.
@smoogipoo

This comment has been minimized.

Show comment
Hide comment
@smoogipoo

smoogipoo Jun 1, 2017

Contributor

So do we still want to merge this one in or look towards merging #775 ? This PR looks fine (also, doesn't bypass acceleration for me either).

Contributor

smoogipoo commented Jun 1, 2017

So do we still want to merge this one in or look towards merging #775 ? This PR looks fine (also, doesn't bypass acceleration for me either).

Vector2 pos = new Vector2(point.X, point.Y);
private void handleMouseEvent(MouseEventArgs e)
{
if (!host.Window.Visible || !mouseInWindow)

This comment has been minimized.

@smoogipoo

smoogipoo Jun 1, 2017

Contributor

Is this conditional required? As far as I can tell it's never being triggered for me, different platform implementation differences?
Am fine with keeping this around but if there is such a difference it should probably be documented.

@smoogipoo

smoogipoo Jun 1, 2017

Contributor

Is this conditional required? As far as I can tell it's never being triggered for me, different platform implementation differences?
Am fine with keeping this around but if there is such a difference it should probably be documented.

This comment has been minimized.

@peppy

peppy Jun 1, 2017

Member

I believe there's a change GetCursorState is called before the window handle is fully created, PointInClient will exception in such cases

@peppy

peppy Jun 1, 2017

Member

I believe there's a change GetCursorState is called before the window handle is fully created, PointInClient will exception in such cases

This comment has been minimized.

@smoogipoo

smoogipoo Jun 1, 2017

Contributor

Aha, triggered it.

@smoogipoo

smoogipoo Jun 1, 2017

Contributor

Aha, triggered it.

This comment has been minimized.

@smoogipoo

smoogipoo Jun 1, 2017

Contributor

Wait but this path hasn't anything to do with PointInClient so it wouldn't exception. Shouldn't this visibility check be added to the GetCursorState path?

@smoogipoo

smoogipoo Jun 1, 2017

Contributor

Wait but this path hasn't anything to do with PointInClient so it wouldn't exception. Shouldn't this visibility check be added to the GetCursorState path?

This comment has been minimized.

@peppy

peppy Jun 1, 2017

Member

yep, this was moved around incorrectly

@peppy

peppy Jun 1, 2017

Member

yep, this was moved around incorrectly

@peppy peppy merged commit ebba962 into ppy:master Jun 1, 2017

1 check passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@peppy peppy deleted the peppy:input-driven-mouse branch Jun 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment