Smithay
Implement a software renderer
We should provide a software-rendering implementation of the Renderer trait, so that Smithay-based compositor can be easily made compatible with contexts without hardware-accelerated graphics, without requiring every compositor project to write their own.
Mains considerations that come to mind:
- it should be able to use both direct DRM or a user-provided buffer as a rendering target (for cases like RDP / VNC)
- What engine should we use? Should we introduce a dependency on
pixman, or is there some relevant and well-performing rust engine?
* it should be able to use both direct DRM or a user-provided buffer as a rendering target (for cases like RDP / VNC)
Some implementation thoughts:
The first one would be solved by implementing Bind<DumbBuffer>, the second one could work through image::ImageBuffer or a similar structure (maybe even a raw-slice, depending on how type-safe we want to make the whole thing).
We also might need to do some color format conversion. The image-crate has some useful traits and types for this, but there are probably other examples out there?
* What engine should we use? Should we introduce a dependency on `pixman`, or is there some relevant and well-performing rust engine?
Searching on crates.io for "software render" gives a bunch of results. Our requirements are not very complicated and could possibly even setup ourselves, as we just want to copy buffers into larger buffers. Instead we need to evaluate, what users of smithay would want to use the renderer for addtionally to rendering client buffers and if they want to use a specific framework. That alone might make pixman very appealing.
Searching on crates.io for "software render" gives a bunch of results. Our requirements are not very complicated and could possibly even setup ourselves, as we just want to copy buffers into larger buffers. Instead we need to evaluate, what users of smithay would want to use the renderer for addtionally to rendering client buffers and if they want to use a specific framework. That alone might make pixman very appealing.
Qubes OS needs accurate damage tracking, and would very much like to avoid the copy in the case where there are no subsurfaces. That would need kernel support, though, and isn’t required. Pixman has the advantage that basically every *nix-like system has it, as it is a dependency of the X.org Server. It also (presumably ― not checked) has decent SIMD acceleration.
