X11 can use XShm for faster rendering

[lunixbochs]

Here's an example usage of XShm (originally from Fabrice Bellard's TinyGL): https://github.com/lunixbochs/tinygles/blob/unstable/src/gles/glx.c#L107

Basically, this allows you to blit pixels directly into X11's memory, saving both a memory copy and the general overhead of passing your image through an X11 socket.

In the non-shm case, you also shouldn't need to create a new XImage every frame as you're doing now. You only really need to do it on startup and when the window is resized. You can just call XPutImage on an existing XImage repeatedly, as done here: https://github.com/lunixbochs/tinygles/blob/unstable/src/gles/glx.c#L368

[john01dav]

Is this motivated by any particular performance or issue in practice? The current code is quite simple and it works very well on the computers that I tested on. As such, I'm hesitant for any change such as this to be introduced if it does not somehow make the library materially better, as complexity trade-offs (and just development time) are here.

[lunixbochs]

This isn't urgent, mostly informational based on past experience. If someone tries software rendering with this on a weaker system, the memory bandwidth requirements for framebuffer copies can end up being the largest overhead.

(I may end up using this crate for my app as part of a software rendering fallback for users without working GPU drivers, and in which case I may offer to implement + support this feature myself)

[john01dav]

FWIW I tried it on a weak, although not embedded weak, laptop (2010 Intel Thinkpad) and it was totally fine. Do you have weaker systems in mind? I'm not really sure how popular X is in the embedded world. If you submit a PR that makes it usefully faster in any specific use case, though, I'll merge it (assuming good code quality, etc.).

[john01dav]

Closing as duplicate of #38 in relation to the merge of swbuf and softbuffer