Skip to content

Conversation

@redawl
Copy link
Contributor

@redawl redawl commented Oct 24, 2025

Description:

Since glfw gives us mouse position every time the callback is called, we can just save the position, and only call processMouseMoved right before we draw each frame. This can make a huge difference when mouse movement events are coming in at a faster rate than the frame rate. Same optimization for window resize events.

There might be other input events where a similar optimization is possible, this is just a start.

Fixes #5815, #3374 possibly #1114?.
Also drastically improves resizing for https://github.com/fyne-io/solitaire :)

Note: Tests for mouseMoved had to be updated, since they expected processMouseMoved to be called internally. I added a helper method for tests that fulfills that assumption.

Checklist:

  • Tests included.
  • Lint and formatter run with no errors.
  • Tests all pass.

@redawl
Copy link
Contributor Author

redawl commented Oct 24, 2025

Hmm, maybe the flaky tests are real this time? I don't see any races in a real application though

@Jacalz
Copy link
Member

Jacalz commented Oct 24, 2025

Hmm, maybe. More likely a race in our test framework than your code, or rather this surfaces those issues more clearly. I think you best bet is looking at those failing tests and seeing if there is any code that runs directly in the test function and not on main. Remember, Go executes each test in its own goroutine so they are not running on the main thread by default like a regular app.

ensureCanvasSize(t, w, fyne.NewSize(72, 123))

w.mouseMoved(w.viewport, 10, float64(e.Position().Y+10))
w.moveMouse(10, float64(e.Position().Y+10))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose lines like this may be the culprit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that putting the necessary codeblocks in runOnMain is causing test runtime to exceed 10 minutes. If anyone has time to look into fixing the unit tests races I would be grateful. Otherwise, I'll keep poking at it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exceeding the deadline normally means a deadlock. Which indicates that the runOnMain was calling something else that is runOnMain inside it. Note that the "safeCanvas" type and others are attempting to automatically wrap so it's not always needed where it appears it might be.

Hopefully that is a clue. I might get a chance to look tomorrow.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants