Cairo Graphics Library Drops OpenGL Support After A Decade Of Inactivity

[kpedersen]

except what was expected is something higher level on top of it.

That higher level thing *is* OpenGL. Since (confusingly) OpenGL is a spec rather than an actual library, many OpenGL mini-shims are written ontop of metal, Vulkan, DX, etc.

Yes, OpenGL is a problematic design but there will never be anything else to replace this because people can't get their sh*t together and make decent standards. Least of all the Gnome guys.

[shmerl]

That higher level thing *is* OpenGL. Since (confusingly) OpenGL is a spec rather than an actual library, many OpenGL mini-shims are written ontop of metal, Vulkan, DX, etc.

Not really. OpenGL as a state machine with poor parallelism is what's bad about it. Higher level without those issues is what's needed.

[Berniyh]

Note that GTK2 is still used by many apps and hasn't gone away, so GTK 3 is going to be around a while. The reason GTK4 was branched is that the new rendering system broke all custom widgets, and both Firefox and libreoffice had just ported to GTK3 and breaking that would have been a major deal-breaker, sending them back to GTK2 or even over to QT.

That would of course be extremely awful. xD

But in all seriousness, Libreoffice actually already supports Qt5 and Qt6 as well as some KDE-specific parts. They also already have GTK4 support. They're basically all over the place.
Firefox did have a Qt branch ages ago with the help of Nokia, but it was not feature-complete and they didn't pursue the idea. Now with Firefox being less popular than back in the day, I doubt they would go into that direction again. Most likely, they'd just branch off GTK and use their own version. I think they would have the resources for that (but possibly not for porting Firefox to Qt).
In the end the better examples would be applications like GIMP or Inkscape. While both of these teams definitely don't have the resources to go for Qt (and most likely wouldn't want to migrate) I think they would be is serious trouble if they're left behind due to some GTK restrictions.

[vtorri]

Are other mature and feature-rich libraries for rendering vector graphics with OpenGL? I know Skia, but it's poorly documented. There is also NanoVG, but it is currently unmaintained. Anything else?

you may look at https://github.com/thorvg/thorvg

[Monsterovich]

User theming is a big misfeature. It makes professional applications nearly impossible because they look bad because they are optimized for an other theme.

No. If something looks bad in a particular theme, it's the theme's fault, not the app's. Most apps look fine, however, and that's not a reason to throw out theme support. It's just that GNOME developers try to make up reasons to throw out theming features.

[mSparks]

Hardware rendering is efficient, but the problem is that it's difficult to make it high quality, all attempts to make hardware rendering, for example, for fonts and various primitives always ends in blurry image and mandatory sub-pixel anti-aliasing in all fonts (look at QML) which you are not able to disable. Not to mention the fact that it may end up with lower performance because it ends up often relying on the CPU for rendering in the end. Because graphical APIs like OpenGL have no features for drawing UIs, they are designed primarily for rendering a large number of triangles, applying shaders and so on.

gpu rendering is hard yes.
Its also easiest and the most portable in opengl.

So basically cairo is abandoning hardware rendering because its hard, but the next version will definately be better....

Oh dear, I suspect that doesn't end well.

[sinepgib]

But in all seriousness, Libreoffice actually already supports Qt5 and Qt6 as well as some KDE-specific parts. They also already have GTK4 support. They're basically all over the place.
Firefox did have a Qt branch ages ago with the help of Nokia, but it was not feature-complete and they didn't pursue the idea. Now with Firefox being less popular than back in the day, I doubt they would go into that direction again. Most likely, they'd just branch off GTK and use their own version. I think they would have the resources for that (but possibly not for porting Firefox to Qt).

It's extremely funny that we write all those widget libraries and what not to abstract the windowing system and be portable and not make applications need to support a million backends, only to end up having too many libs and applications supporting more backends than we initially had.

[zboszor]

Everyone seems to forget that Cairo is so much more than just drawing on the screen.

Sure, it can do that for many different windowing systems. So what if an accelerated *client side* rendering is removed for being unmaintained? The server side rendering may still be accelerated.

But there are many other backends to draw on. For one, there's a first class PDF backend and a few image formats.

[carewolf]

Are other mature and feature-rich libraries for rendering vector graphics with OpenGL? I know Skia, but it's poorly documented. There is also NanoVG, but it is currently unmaintained. Anything else?

Qt.. For instance QPainter from QtGui on an QOpenGLWindow, or the QtQuick scenegraph.

[carewolf]

Vulkan was never meant as a replacement for OpenGl.

It will ALWAYS co-exist with OpenGL. I remember clearly how Kronos stated it again and again, and it was stated by other parties too.

Yeah, but the fact that OpenGL was already often accessed through libraries, and those libraries now switching to Vulkan. You may see a migration anyway, because OpenGL was rarely used directly as intended in the first place, so Vulkan might be a full replacement as a backend to libraries.