Make softbuffer window contexts own the pixel buffers.

[i509VCB]

At the moment all backends need to perform a copy to present. Some backends such as Wayland (always) and X11 (with the SHM extensions) can simply share the pixel memory with the server. On Windows and Mac this saving wouldn't be possible, but it would help on other platforms.

Not sure what redox does in this case.

[ids1024]

Should be possible with dumb/gbm buffers for #42 too, right? Though the implications of working with references into mmaped gbm buffers may be subtler than just shared memory.

Also to provide a slice into an shm buffer, we technically trust the compositor to not modify it for soundness. This is probably fine (and less a concern than the reverse) but it's something to be aware of.

[i509VCB]

Should be possible with dumb/gbm buffers for #42 too, right? Though the implications of working with references into mmaped gbm buffers may be subtler than just shared memory.

Also to provide a slice into an shm buffer, we technically trust the compositor to not modify it for soundness. This is probably fine (and less a concern than the reverse) but it's something to be aware of.

With dumbuffers I believe that would be possible. GBM I guess mapping memory is weird there.

[jackpot51]

Redox supports memory mapping window buffers. In fact it is the only way to draw anything. The only problem is the memory needs to be remapped on window resizes, which may complicate the API.

[i509VCB]

If we need to ensure that the buffer can't be resized while drawing, we could use a closure in the function to access the buffer which takes an &mut reference.

[notgull]

Also to provide a slice into an shm buffer, we technically trust the compositor to not modify it for soundness. This is probably fine (and less a concern than the reverse) but it's something to be aware of.

According to the people that I've talked to about this, it may not actually be sound. On the X11 end, it's entirely possible for someone to write an implementation of the X server that maliciously modifies that buffer, and then run that server using our Rust program as a client. While the protocol says that the buffer can't be modified mid-transmission (or at least, not without the appropriate X11 events being delivered), there's nothing really stopping the server from disobeying it. I'm not sure about the Wayland end but I'd imagine that a similar problem exists.

A copy may unfortunately be necessary in the name of safety, in this case.

[i509VCB]

Yes the server can clobber the entire buffer on Wayland. But every client that has damage relies on the compositor not clobbering said buffer.

No client I've seen however assumes the server will trash the buffer unless given to something like wlr-screencopy which writes to the shm buffer.

[ids1024]

This is the same concern I mentioned earlier. There are a few considerations here:

• With backends like DRM, presumably this is guaranteed to avoid mutation barring a bug in the kernel or graphics driver. And we rely on a correct and non-malicious kernel for soundness anyway.
• With Wayland this could be a concern, but as far as malicious modification, the server normally has the same or greater privileges than the client, so trusting the compositor might be reasonable?
  • Similarly with X. Or in remote use cases you wouldn't be able to use shm anyway.
• I don't think this is likely to lead to exploitable vulnerabilities in practice even with a malicious server, but that's hard to be sure of. And more complicated in a library since the user could potentially be doing things other then merely writing bytes without reading anything.
• If we don't trust the server for soundness, we could still provide such an API, but it couldn't provide a slice into memory. But it is possible to provide a custom helper type with a custom Index implementation, etc.
  • If so, we'd probably want to provide this no-copy interface in addition to the simpler set_buffer API, rather than only providing it.

[i509VCB]

There is a significant usability harm if we aren't exposing slices. Many libraries like tiny-skia's PixmapMut takes a mutable slice.

[ids1024]

Yes, for a lot of APIs you would want the buffer or a part of it as a slice, so this could be quite limiting. While for some uses it would mostly work alright.