Can't write new pixels to winit window via graphics context after pixels are already written

[john01dav]

I am the author of the library Softbuffer, a library that integrates with winit to show a 2D buffer in a window without GPU acceleration (and thus it's more widely compatible than GPU-based systems). It uses core-foundation-rs for its Mac OS support, which was PR'd by someone else as at the time of writing I did not have access to a Mac OS computer.

Since then I have gained access to an old one (won't run anything newer than High Sierra, in case that matters) and I have found a bug in their implementation and I've been trying to fix it over the past few days to no avail. The issue is that when a buffer is shown on the window (via draw_image) then another can't be shown again until the window resizes. That is, if there is an attempt show another, the old image remains in its place.

I've been pouring over the relevant documentation from Apple, and I can't find anything wrong with the PR'd code based on that. I also tried guessing various things (like recreating the graphics context each time a new buffer is drawn), but each failed in some way (recreating the graphics context returns null instead of a new context, for example).

As such, I'd like to ask for help with fixing this. I don't think that it's likely that it's a bug in core-foundation-rs, but this seems like the best place to ask this where there will be a concentration of people who will know how to help. If you have any examples of using core-foundation-rs with winit, that would also be very useful since then I can compare to the code in my library.

Here is the code that implements Mac OS support via core graphics: https://github.com/john01dav/softbuffer/blob/master/src/cg.rs

Here is a demo that tries to show an animation, and can reliably reproduce the bug (to run, clone this repo then cargo run --example animation): https://github.com/john01dav/softbuffer/blob/master/examples/animation.rs

I would greatly appreciate any help that you are able to provide.

[jrmuizel]

I haven't looked in detail at the problem you're having but it reminded me of rust-windowing/winit#1605 which I ran into in the past.

[jrmuizel]

I don't think winit is calling setNeedsDisplay on the view. That might be the problem.

[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.