Add explicit support tiers#323
Conversation
| | Wayland | 1 | ✅ | | ||
| | Win32 | 1 | ✅ | | ||
| | XCB / Xlib (X11) | 1 | ✅ | | ||
| | Android NDK | 2 | ✅ | |
There was a problem hiding this comment.
I would commit to 1 on Android too, if it weren't for the remaining issues in android-activity and winit.
There was a problem hiding this comment.
I'm kind of of the same mind for iOS / UIKit (and Web to a certain extent), the problems there aren't in Softbuffer but in Winit. But effectively, it does mean that Android and iOS are less supported, hence tier 2.
| | WebAssembly | 2 | ✅ | | ||
| | DRM/KMS | 3 | ✅ | | ||
| | Orbital | 3 | ✅ | | ||
| | GBM/KMS | N/A | ❌ | |
There was a problem hiding this comment.
Are users interested in a GBM backend - which uses DRM/KMS?
There was a problem hiding this comment.
Idk how GBM works, I just kinda filled out the table based on RawWindowHandle
There was a problem hiding this comment.
As long as the gbm_surface uses a linear modifier, we could mmap it and write to it, but I'd assume for pure software rendering using dumb buffers would perform better, or equivalently?
There was a problem hiding this comment.
I think it makes sense to list it here anyhow, regardless of whether we ever intend to support it, since it's part of raw-window-handle.
madsmtm
force-pushed
the
madsmtm/support-tiers
branch
from
cb9a69f to
aa04cb3
Compare
By adding a pull request template with the tier list.
4 participants
I don't really know how DRM/KMS works, and I don't have Orbital/Redox in a VM, so for the changes I've been making recently, I haven't tested those platforms.
I'd argue that this is fine, I think those platforms are fine to be less supported than the others, but we should document this somewhere. Additionally, while I try to make Android, Web and iOS work, these are also gonna be less tested in practice.
For this, I propose introducing three "support tiers" in a similar vein as rust-windowing/winit#3887. I went with only listing platforms, and not
rustctargets, since there isn't any target- / architecture-specific code to speak of in Softbuffer (apart from endianess checks, which I documented to be less tested on big endian in this PR too).