NSGraphicsContext::currentContext not accessible from redraw handler on macOS

[jrmuizel]

Calling msg_send![class![NSGraphicsContext], currentContext] returns null when called from the winit event loop. I suspect this is because the currentContext is only valid while drawRect is being called.

Not being able to get the currentContext makes winit unusable for drawing on macOS unless OpenGL or Metal is used.

[john01dav]

I'm working on a 2D framebuffer crate as well and it seems that this isn't an issue. The Mac OS code in my crate gets the graphics context in the same way, but there's another issue. Perhaps you can help with this? I'd very much like there to be a working GPU-less 2D framebuffer crate for winit. To address the issue that you had the RedrawRequested event handler is called from within draw_rect, so as long as you do your drawing there it should be fine. I found this out by having a debugger check the stack trace when handling this event.

EDIT: I didn't notice that you were the same person at first, sorry. I think that I have a lead to fix this, though. Thanks for linking me here!

[john01dav]

Okay, so it turns out that RedrawRequested in winit isn't always called from draw_rect. Specifically, it isn't when it happens due to a requested repaint. If instead of requesting the repaint from winit, I send setNeedsDisplay:YES to the view, then winit calls the RedrawRequested event from draw_rect, which I thought would resolve teh sisue that I'm having with by GPU-less crate, but it did not. Nonetheless, your original issue appears to be solved this way (and a PR to winit to make request_repaint() trigger setNeedsDisplay: YES when on AppKit would seem to be in order), maybe you know how to solve mine?

[jrmuizel]

Can you push the updated version of softbuffer that does this?

[john01dav]

Can you push the updated version of softbuffer that does this?

I made the setNeedsDisplay change not in softbuffer but in one of the examples (the animation one, the only one that is broken on mac os as the others just display a static image). I did so in a quick and dirty testing way (I just added the setNeedsDisplay call directly in the example, so it won't compile on anything except Mac OS). Nonetheless, it should be sufficient to demonstrate the issue, so I've uploaded it as a zip here. I didn't want to push such a quick and dirty version to the main repo.

The correct place to put the setNeedsDisplay call is in winit, and I didn't want to dig through it to figure out exactly where and deal with a non-standard version for testing when it might not even work. Of course, if this ever works, I'll submit a PR to winit to add it in.

To reproduce the issue, run the animation example which behaves the same as the animation example in the repo, except it only updates once per second. It's a fairly trivial change (in examples/animation.rs) to make it update continuously.

softbuffer.zip

[john01dav]

It turned out that I had missed something obvious in my testing of setNeedsDisplay. It was actually working, but because I had slowed the update rate to 1Hz and because the animation is one second long it was showing the same frame each time and thus appearing to not work. Once I increased the animation speed back to where it should be, everything works. I have now made a PR to winit about setNeedsDisplay. This PR should resolve this issue.