Skip to content
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

MacOS doesn't redraw while window resize is held but not moving #455

Open
markmurphydev opened this issue Jun 17, 2024 · 4 comments
Open

Comments

@markmurphydev
Copy link
Contributor

Running the Quad example on MacOS on master, the window does not draw while the corner is held, but does draw while dragging it around to resize.

miniquad_quad.mov

This was introduced in #443

@markmurphydev
Copy link
Contributor Author

I think this is relevant:
rust-windowing/winit#219

@markmurphydev
Copy link
Contributor Author

markmurphydev commented Jun 18, 2024

So the general issue seems to be that when [ns_app sendEvent:event] gets a NSLeftMouseDown event that would resize the window, it switches into an internal event tracking run loop, which doesn't return control to macos::run until resizing is finished.

If you re-add the draw timer from before #443, but set the mode to NSEventTrackingRunLoopMode, it will draw while resizing, and the callback is only called while resizing.
I don't really know what the behavior is supposed to be for blocking_event_loop, but if you don't want it to draw continuously while resizing, you could create the timer only if it's not blocking.

I'm not sure how [ns_app run] redraws during resizing if it's also calling sendEvent.

@birhburh
Copy link
Contributor

birhburh commented Jun 23, 2024

@markmurphydev, I wrote new implementation (basically copied it from android and ios)
https://github.com/birhburh/miniquad/tree/blocking_event_loop_osx
It is still raw but resize should work already
I'm still adding all messages processing

@markmurphydev
Copy link
Contributor Author

I noticed that the window also freezes while any drop-down on the osx top menu bar is open, but this is also fixed by #462

birhburh added a commit to birhburh/miniquad that referenced this issue Aug 11, 2024
- Reverted macos.rs to this implementation:
not-fl3#443 (it's probably better compare changes with this PR than with latest commit to understand what was added additionally)
- Now using own NSView with NSOpenGLContext instead of NSOpenGLView
- For metal backend using redraw instead setNeedsDisplay, because somehow it reduces cpu usage (Cannot find info about enabling vsync like this in MTKView docs)
- Fixed freezing on resize by drawing in draw_rect that called during "live resize"™. I don't like this approach, but it blocks main event loop while resizing, so it will not be some kind of concurency of opengl stuff i think
- Reducing CPU usage when window is occluded
- Added comments to hacky places, there are lots of them imo

Fixes:
- not-fl3#455
- not-fl3#470
not-fl3 pushed a commit that referenced this issue Aug 11, 2024
- Reverted macos.rs to this implementation:
#443 (it's probably better compare changes with this PR than with latest commit to understand what was added additionally)
- Now using own NSView with NSOpenGLContext instead of NSOpenGLView
- For metal backend using redraw instead setNeedsDisplay, because somehow it reduces cpu usage (Cannot find info about enabling vsync like this in MTKView docs)
- Fixed freezing on resize by drawing in draw_rect that called during "live resize"™. I don't like this approach, but it blocks main event loop while resizing, so it will not be some kind of concurency of opengl stuff i think
- Reducing CPU usage when window is occluded
- Added comments to hacky places, there are lots of them imo

Fixes:
- #455
- #470
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

No branches or pull requests

2 participants