LoganDark

> sooner than just before drawing This isn't really a thing because you want to draw immediately after a window resize. So there's never going to be any significant gap...

> We'll probably need to expose a `stride` to efficiently implement #44 using https://developer.android.com/ndk/reference/struct/a-native-window-buffer#struct_a_native_window___buffer > > So I think we'll ultimately want an API change like this. I would highly...

> Is `imgref` currently used in any crates that would likely be used with Softbuffer for rendering? > > We need the `Buffer` type to provide a `present` method, and...

> Unfortunately it seems we need to use RGBA on some platforms for no-copy presentation Well right now you say `u32`. Using the dedicated structs from [`rgb`](https://docs.rs/rgb/latest/rgb/) crate would be...

Now that I've had the opportunity to test `softbuffer` `0.3.0` with managed buffers, I can confirm that drawing a new frame into a 4K buffer can now be done in...

I left this open because my impression was that presenting is still slow on macOS (arguably more common since basically every Mac has a HiDPI display)

Softbuffer always (should always??) uses physical pixels. Your issue is that macOS is scaling the application because it doesn't know it supports HiDPI. You have to find the binary in...

> I think that this should not be worked around in the application, softbuffer should apply the contents scale factor to the layer it creates as if the application rendered...

> I pretty strongly believe that the conversion from logical to physical should happen in the consumer of `softbuffer`, and that `softbuffer` should always present physical pixels. exactly

> I don't really get what you mean What I mean is that the frame wait results in a race condition where the window can be resized after Fabrishot resizes...