3 ms·

Is there any advantage to using OpenGL even if one isn't interested in 3D effects in either the compositor or applications? IIUC, the Weston reference composito

Is there any advantage to using OpenGL even if one isn't interested in 3D effects in either the compositor or applications? IIUC, the Weston reference compositor has a back-end that doesn't require OpenGL but just uses the framebuffer device and pixman. Wouldn't that be faster on systems that don't have 3D hardware, or that don't have free drivers for that hardware (e.g. some ARM boards)?

Sir_Cmpwn 9y ago
We don't just paste pixels on the screen, we composite them. This involves alpha blending, projecting the scene onto an orthographic output projection, and more. Even in two dimensions, OpenGL is very useful here. On systems without suitable hardware, you should be able to use OpenGL in software (via mesa) and it will still be very fast here.
- mwcampbell 9y ago
  Ah, thanks for that clarification; I'm pretty ignorant about graphics. Good to know that Mesa will be fast in this case. I tried running full-blown GNOME on an ARM board (Wandboard) without proper driver support for the GPU, and GNOME Shell used ~40% of a CPU at idle. I'm guessing that something like Sway, even though it uses OpenGL, is less demanding.
  - emersion 9y ago
    Even with software rendering, a wlroots compositor should use 0% when idle thanks to damage tracking (ie. only redrawing parts of the screen that changed).
emersion 9y ago
A fbdev backend and a pixman renderer are planned for this kind of situations. However, most desktop computers and laptops support OpenGL ES 2, and using them in the compositor offers better performance than using the CPU even if there aren't fancy 3D effects.
aspaceman 9y ago
A helpful exercise is to consider the work that a compositor actually does and then try implementing a simple CPU-based one. The main operation you'll need is a blit - which you'll find somewhat difficult to optimize. Hardware-accelerated blitting (OpenGL) is so much faster that it's entirely worth it. The only tradeoff is the complexity of OpenGL, but Mesa or other libraries can abstract all of that away.

Sir_Cmpwn 9y ago

We don't just paste pixels on the screen, we composite them. This involves alpha blending, projecting the scene onto an orthographic output projection, and more. Even in two dimensions, OpenGL is very useful here. On systems without suitable hardware, you should be able to use OpenGL in software (via mesa) and it will still be very fast here.

mwcampbell 9y ago
Ah, thanks for that clarification; I'm pretty ignorant about graphics. Good to know that Mesa will be fast in this case. I tried running full-blown GNOME on an ARM board (Wandboard) without proper driver support for the GPU, and GNOME Shell used ~40% of a CPU at idle. I'm guessing that something like Sway, even though it uses OpenGL, is less demanding.
- emersion 9y ago
  Even with software rendering, a wlroots compositor should use 0% when idle thanks to damage tracking (ie. only redrawing parts of the screen that changed).

emersion 9y ago

A fbdev backend and a pixman renderer are planned for this kind of situations. However, most desktop computers and laptops support OpenGL ES 2, and using them in the compositor offers better performance than using the CPU even if there aren't fancy 3D effects.

aspaceman 9y ago

A helpful exercise is to consider the work that a compositor actually does and then try implementing a simple CPU-based one. The main operation you'll need is a blit - which you'll find somewhat difficult to optimize. Hardware-accelerated blitting (OpenGL) is so much faster that it's entirely worth it. The only tradeoff is the complexity of OpenGL, but Mesa or other libraries can abstract all of that away.