Ian Douglas Scott

Not doing conversions makes things simpler, definitely. The trouble there is if there is no format that is supported on all backends. If we don't do conversion, does that mean...

Making `Buffer` an `enum` makes a certain amount of sense. But I think we want an API that lets the caller choose between multiple different formats out of those that...

If we're unsure about non-u32 formats, we can leave those out for now, and update the ABI for that later (possibly in a breaking way). I'd definitely say the priorities...

> I'm not sure I properly understand how https://github.com/rust-windowing/softbuffer/issues/90 plays a role here, could you elaborate? The goal of buffer age is to allow redrawing only part of the buffer,...

Creating a `Context` requires a `RawDisplayHandle`, while creating a `Surface` requires a `RawWindowHandle`. So on Wayland the `RawDisplayHandle` represent a particular connection to a Wayland server, while the `RawWindowHandle` represents...

We're not currently using that API for the Wayland backend, we're currently using `wl_shm` where there are no differences between surfaces. This would be if we wanted to use a...

> Also, do we publicly expose the underlying enum type, or do we wrap it so that the actual enum is private, allowing us to change it if we need...

Using `ANativeWindow_lock`, is there a way to request that the window uses an `BGRX` buffer like SoftBuffer currently assumes? Or would we have to deal with a different pixel format?...

Right. Hopefully we can at least expect `RGBX` to always work? In comparison Wayland's `wl_shm` has a huge list of formats but only requires a compositor to support `argb8888` and...

Currently, I think https://github.com/rust-windowing/softbuffer/issues/98 is the most important missing feature/API in softbuffer. It's awkward if some platforms only support RGBX/RGBA but others only support BGRA/BGRX. We'll want an API that...