Search code examples
cairoawesome-wm

Would it be difficult to have AwesomeWM use the cairo-gl backend of cairo?

Basically, the question. As far as I know, AwesomeWM does not use the cairo-gl backend when using cairo.

Would it be difficult to make AwesomeWM maybe check "do we have a gpu? if yes, do we have OpenGL support? if yes, use the cairo-gl backend. if not, use the software renderer." I am asking this because it would be nice for things like fast (100 fps+) animations.

Solution

  • There are reasons why the Cairo OpenGL backend never became very popular and why the Vulkan one was abandoned. Cairo was also abandoned by Safari, Firefox and Chrome because they could not improve the speed much further.

    Cairo API uses a "context" (cr) object to track the painting operation as part of transactions (which are completed with calls such as :fill(), :paint() and :stroke()).

    All of those are state machines that heavily depend on the CPU to synchronize them. So even if you use painting primitives from OpenGL, the control flow remains pretty much the same. This nullify any performance advantages because for the efficiency gains you get from processing in the GPU, you had a ton of context sync between the CPU and GPU.

    Something like the Skia library (and QtQuick) is better suited to unlock the GPU power. They use a different mechanism to to sync the state between the application side scene graph and the GPU textures. This is a lot closer to a 2D game engine than a traditional painting API. However Skia has its fair share of problems too. The largest is the lack of official API stability (idk if that has changed). The other, for Awesome in particular, is the lack of proper Lua bindings which are compatible with glib event loop.

    Last, but not least, all AwesomeWM widget boxes (wibox, wibar, titlebar, etc) are managed by the same CPU thread. This is the real bottleneck for animations, not the painting speed. Every frame requires the Lua VM thread to perform every single Cairo transactions and repaint every affected areas. Then, with the OpenGL backend, it would have to to sync every each of those individually to the GPU.

    So, tl;dr, it would not be faster and it would be less stable. If you need more speed, you can work on improving how LGI works. Changes like this one could make it ~5x faster. Of course, ensuring this is done properly and regresses nothing wont be trivial. But it's a low hanging fruit to increase the FPS.