Clarify maintainership

[madsmtm]

• Added @jackpot51 as Redox maintainer.
• Added myself as macOS maintainer

[madsmtm]

Anyone interested in owning the other platforms @ids1024, @notgull, @tronical?

[tronical]

I'd been looking for something like this crate for a long time, and only very recently discovered soft buffer and found it to finally tick the boxes I was looking for. So I'm even more delighted to see the fork under the umbrella here and I subscribed to GH notifications for this repo. I'm familiar with the other platforms in general but not swbuf's specific implementation.

[jackpot51]

Would be good to ask the winit maintainers for each platform. I have the ability to test changes for all platforms but web (until I figure out how that is supposed to be tested), but I don't understand any except the Redox/Orbital platform in enough depth to be maintainer.

[jackpot51]

If we don't find anyone for X11 or Wayland I would like to take those on.

[madsmtm]

Any winit maintainers interested in maintaining this?

• Windows: @msiglreith @maroider
• X11/Wayland: @kchibisov

Also pinging Android people (@rust-mobile @rib @MarijnS95 @dvc94ch @msiglreith) to see if any of those would be interested in adding an Android implementation of this?

[notgull]

@madsmtm I could take on the Windows backend and/or the X11 backend.

[ids1024]

I can maintain the Wayland backend.

[madsmtm]

Cool, I've sent you an invite to the repo!

(Note that multiple people can be "maintainer" of each platform, and I mean, we're all in it together, it's mostly to give contributors some sort of expectation of who to ping if they want their change going through).

[MarijnS95]

Also pinging Android people to see if any of those would be interested in adding an Android implementation of this?

swbuf is purely CPU/software side, right? I feel ashamed enough to say that I wrote support for that in the NDK but never ended up finalizing/PR'ing it because of the many different types of texture formats used by default on different devices:

https://github.com/MarijnS95/ndk/compare/window-lock

Maybe an Android backend would incentivize to pull that over the finish line.

[ids1024]

There's been some discussion about whether using DX11 or DX12 would be better than GDI on Windows, so I guess the goal would be to use whatever mechanism is best on Android to get an image onto the screen. I don't know what the NDK APIs are like.

[MarijnS95]

On a proper compositor/gralloc the buffer returned by Android here should ¹ be a pointer to some DMA that is accessible by the DRM hardware (i.e. a DRM plane) that it can scanout directly (and why odd formats and strides are forced on the user here). On the contrary using a GPU API for purely CPU draws typically involves some sort of memcpy to the GPU (unless a write happens directly to device/host visible DMA buffer, most phones use a UMA anyway), a shader launch that performs a copy (typically by rastering a fullscreen quad, though Vulkan has other options), and finally a present to the screen via said graphics API.

On desktop you typically need something like that anyway though, to get pixel data out of system memory into the dedicated GPU where presentation hardware and the physical connector to a monitor lives.

Regardless, Android's ANativeWindow_lock() API is the most simple/convenient to use.

Footnotes

1. I could be totally wrong here and Android might always be copying/converting data internally, though that doesn't jive with their design that favours power-efficient passing of buffer handles rather than the underlying data. ↩

[john01dav]

Hi, I'm the original softbuffer maintainer. Sorry for not being as active with reviewing PRs and such as I'd like to have been. Some circumstances, most recently just being busy, prevented me from doing so. There are a lot of good changes here, and I don't think that it makes much sense to fragment things when we have the original softbuffer crate.

As such, I'd like to propose this:

• move softbuffer repository to rust-windowing
• incorporate the commits here into softbuffer, could also just rename this to softbuffer and make the old repository into a link to this one
• publish new softbuffer crate with these excellent changes
• yank the existing version of swbuf on crates.io and update it to redirect to the softbuffer crate, to clarify for users which one to use

After that, I can help coordinate changes between each platform maintainer. Unfortunately I am not an expert in any of these platforms (as was probably obvious to everyone who looked at some of my platform code), so taking a particular platform myself may not be ideal — but I can absolutely coordinate the changes between platforms, external API updates, etc. to get updates pushed out properly and going forward I expect to have more time (after working through what was keeping me busy). I can also add some other people on the crates.io package in case I do get busy again.

If you all don't want me involved after being gone like that, I understand, but I do care about this library and I'm thrilled to see it getting so much attention from people who know more about these platforms than I do so I'd like to remain involved in this capacity.

[ids1024]

Really the most important thing is to figure out the best API for someone how just wants a way to put pixels on the screen in a cross-platform without an intimate knowledge of each backend (while conforming to what is possible and efficient across backends).

incorporate the commits here into softbuffer, could also just rename this to softbuffer and make the old repository into a link to this one

If want to move the softbuffer repo here, we can transfer all the issues currently on swbuf to softbuffer easily enough.

[john01dav]

Really the most important thing is to figure out the best API for someone how just wants a way to put pixels on the screen in a cross-platform without an intimate knowledge of each backend (while conforming to what is possible and efficient across backends).

I've been mulling over how to improve the API based on some issues that were raised previously, so I have some thoughts here.

I see 4 potential issues with the API as it stands now:

1. no way to damage part of a window when updating part or all of it
2. no way to update part of the window, requiring
3. use of u16 for set_buffer
4. no support for anything other than 8 bit color depth

Of these, I'm only certain that 3 needs to be fixed. Frankly, I don't know why I made it u16 to begin with. It was the wrong choice, but also a trivial fix.

For 2 and 3 I see two general possibilities for how to fix it. We could add more methods alongside set_buffer to handle specific cases more efficiently, like updating a specific part of the buffer or updating the whole buffer but only damaging part of it. We could also expose something superficially resembling Vulkan's swapchain API to allow the user to have multiple explicit buffers that are shared between the platform backend and the user's code, where they can set which is displayed and edit the ones that are not displayed. You can have specific areas marked as damaged when swapping buffers. The question, which I pose to each platform maintainer, is if this buffer-swapping API is feasible. It does seem like it should be possible at least on some, which may be a strong enough reason to go with it — it is possible to have a copy-style implementation behind this API.

For 4, the fix seems orthogonal to the other fixes. We need some way to consider formats that are supported variously between different backend APIs, and also some way for users to write to a window without having to worry too much about that. Again, taking a page from Vulkan seems reasonable here — we can have a set of known formats, a set of supported formats, and at least one guaranteed-supported format. Also, to ease the difficulty of supporting several formats, it may make sense to add an optional Buffer struct which stores a buffer and its format, and exposes higher level functions like set_pixel and get_pixel. This may be best placed in a different crate, however, as rendering is outside the scope of softbuffer as a platform abstraction library.

If want to move the softbuffer repo here, we can transfer all the issues currently on swbuf to softbuffer easily enough.

I'll also need to transfer the commits, but that's easy enough. I'm ready to execute this transfer once someone on rust-windowing is ready to coordinate on that end.

[madsmtm]

Great to hear @john01dav! - And no worries about being absent, we all have a life outside of open source, and motivation is a hard thing to come by!

I've sent you an invite to the organization, and have trired to set up the permissions such that you can transfer the repo - let me know if you need something else

[madsmtm]

When you get there, would you mind adding maybe @kchibisov, @jackpot51, @notgull, and myself to the crate? Then I can add @rust-windowing/publishers to the crate as well, and then we should be fairly good on that front.

Also, people are quire active on Matrix wrt. softbuffer recently, so you may want to join that (also to be easier to reach ;) )

[madsmtm]

Moved to rust-windowing/softbuffer#47 since the repository was transfered