4 ms·

Something as foundational and important as a 2d canvas library is never going to be "finished" and can't just be abandoned aside from the occasional security fi

by necubi 6y ago

Something as foundational and important as a 2d canvas library is never going to be "finished" and can't just be abandoned aside from the occasional security fix. Examples of things you would need to have added in the past few years to stay competitive: * Vulkan support * Emoji support (although I'm not familiar enough with Cairo to know if shaping is part of the library) * Rendering in compute shaders * New platform support (like MacOS arm or Android) Already many users have switched to Skia which continues to make progress in all of these areas (and which is much faster).

Lammy 6y ago
> (although I'm not familiar enough with Cairo to know if shaping is part of the library) That would be its sister project Pango: https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/ https://blogs.gnome.org/mclasen/2019/05/25/pango-future-dire... https://bugzilla.redhat.com/show_bug.cgi?id=1753295 https://bugzilla.redhat.com/show_bug.cgi?id=1753295
jolmg 6y ago
Why does it need development of new features to not be dead? Calling it dead implies that projects that are currently using it shouldn't use it anymore, but projects for which cairo as-is suffices will continue to work with the features that cairo already has, so why would they need to migrate?
- binarycodedhex 6y ago
  Consumer-oriented novelty obsession (new == better + secure) and code churn "job security." If something works and is quality for what it does, it works. Does "ls" really need to be perpetually maintained with minor, inconsequential refactorings if it already works perfectly? If something has bugs or lacks features, then it needs maintenance. "Maintenance" for pushing out versions to fulfill expectations of "maintained" is pointless.
- necubi 6y ago
  If I'm deciding what library to use, I'm not only concerned with whether it meets my needs today, but also whether it will meet my needs in a year or two. I don't necessarily know what those will be but I want to know that the core libraries I'm relying on will keep up with the industry so that my application isn't left behind without a costly rewrite. Just as a simple example, if my competition is using a non-dead rendering library and their UI is twice as fast as mine as a result, I'm not going to be happy.
  - pessimizer 6y ago
    Then (in the hypothetical) you should use what your competition uses and not use Cairo; Cairo wouldn't be vying for your attention, and Cairo doesn't make money when you use it so wouldn't care what you use. If there's a FOSS competitor worth leaving for, that means the environment is healthy.
    - zepto 6y ago
      It doesn’t really in this case. The only alternative is maintained by Google and is much harder to use.
      - boudewijnrempt 6y ago
        skia isn't the only alternative. Qt includes a pretty complete 2D painting engine as well.
        Elv13 6y ago
        Says the one who made the best/most_complex open source one rather than use QPainter ;) But really, QPainter suffers from a lot of the same issues as Cairo (and then some). The main "problem" with them is that they are CPU bound. Both of them have OpenGL backends, but they are not "really" faster. There is also the fact that the Qt Company doesn't invest in it anymore since QtQuick2 was released. Because of that, it doesn't get some of the newer Skia features. So Cairo/QPainter are pretty good at server side rendering. Qt was never popular for that use case. Cairo used to own that market, but it's usage is declining due to the maintenance inactivity issues. Also, once upon a time Cairo was used in Firefox and Chrome, so it's SVGs tend to be rendered more accurately in modern browsers than Qt ones. Skia itself is an unsustainable library to depend on. Its API and behaviour isn't stable. Google doesn't really care about non-Google use cases, so the CMake is broken 90%+ of the time. It adds a large maintenance burden on projects trying to use it. Distributions also hate it for being impossible to package reliably. In turn, it makes hard for smaller projects to migrate away from Cairo because users have an easier time getting their hands on Cairo than Skia. (bias disclaimer: I worked with both as a KDE dev and as the AwesomeWM co-maintainer, a Cairo based project. A lot of the recent unreleased Cairo commits originates from the AwesomeWM community, but not from me)
- bjourne 6y ago
  Because Cairo was an attempt to abstract drawing operations over multiple heterogeneous drawing devices. In theory, Cairo should give you accelerated OpenGL rendering, PDF rendering, GDK rendering, PNG rendering, Win32 rendering, etc behind a "convenient" PostScript-like interface. Thus, when these devices gets new features Cairo must also be updated to exploit these new features. That was the theory behind Cairo. In practice it never worked out and Cairo wasn't able to fully exploit hardware accelerated rendering. Cairo was very complex so it wasn't easy for the maintainers to keep all the various backends up to date.
Ologn 6y ago
Yes. Oh my goodness, look through the open issues. Look at the pull requests. What is the big O run time of the various functions? Sometimes someone pops in from a university and knows how to improve an algorithm and shrink its runtime, perhaps based on the latest graphics research, perhaps based on old research which was somehow missed.

by necubi 6y ago

Lammy 6y ago

> (although I'm not familiar enough with Cairo to know if shaping is part of the library) That would be its sister project Pango: https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/ https://blogs.gnome.org/mclasen/2019/05/25/pango-future-dire... https://bugzilla.redhat.com/show_bug.cgi?id=1753295 https://bugzilla.redhat.com/show_bug.cgi?id=1753295

jolmg 6y ago

Why does it need development of new features to not be dead? Calling it dead implies that projects that are currently using it shouldn't use it anymore, but projects for which cairo as-is suffices will continue to work with the features that cairo already has, so why would they need to migrate?

binarycodedhex 6y ago
Consumer-oriented novelty obsession (new == better + secure) and code churn "job security." If something works and is quality for what it does, it works. Does "ls" really need to be perpetually maintained with minor, inconsequential refactorings if it already works perfectly? If something has bugs or lacks features, then it needs maintenance. "Maintenance" for pushing out versions to fulfill expectations of "maintained" is pointless.
necubi 6y ago
If I'm deciding what library to use, I'm not only concerned with whether it meets my needs today, but also whether it will meet my needs in a year or two. I don't necessarily know what those will be but I want to know that the core libraries I'm relying on will keep up with the industry so that my application isn't left behind without a costly rewrite. Just as a simple example, if my competition is using a non-dead rendering library and their UI is twice as fast as mine as a result, I'm not going to be happy.
- pessimizer 6y ago
  Then (in the hypothetical) you should use what your competition uses and not use Cairo; Cairo wouldn't be vying for your attention, and Cairo doesn't make money when you use it so wouldn't care what you use. If there's a FOSS competitor worth leaving for, that means the environment is healthy.
  - zepto 6y ago
    It doesn’t really in this case. The only alternative is maintained by Google and is much harder to use.
    - boudewijnrempt 6y ago
      skia isn't the only alternative. Qt includes a pretty complete 2D painting engine as well.
      - Elv13 6y ago
        Says the one who made the best/most_complex open source one rather than use QPainter ;) But really, QPainter suffers from a lot of the same issues as Cairo (and then some). The main "problem" with them is that they are CPU bound. Both of them have OpenGL backends, but they are not "really" faster. There is also the fact that the Qt Company doesn't invest in it anymore since QtQuick2 was released. Because of that, it doesn't get some of the newer Skia features. So Cairo/QPainter are pretty good at server side rendering. Qt was never popular for that use case. Cairo used to own that market, but it's usage is declining due to the maintenance inactivity issues. Also, once upon a time Cairo was used in Firefox and Chrome, so it's SVGs tend to be rendered more accurately in modern browsers than Qt ones. Skia itself is an unsustainable library to depend on. Its API and behaviour isn't stable. Google doesn't really care about non-Google use cases, so the CMake is broken 90%+ of the time. It adds a large maintenance burden on projects trying to use it. Distributions also hate it for being impossible to package reliably. In turn, it makes hard for smaller projects to migrate away from Cairo because users have an easier time getting their hands on Cairo than Skia. (bias disclaimer: I worked with both as a KDE dev and as the AwesomeWM co-maintainer, a Cairo based project. A lot of the recent unreleased Cairo commits originates from the AwesomeWM community, but not from me)
bjourne 6y ago
Because Cairo was an attempt to abstract drawing operations over multiple heterogeneous drawing devices. In theory, Cairo should give you accelerated OpenGL rendering, PDF rendering, GDK rendering, PNG rendering, Win32 rendering, etc behind a "convenient" PostScript-like interface. Thus, when these devices gets new features Cairo must also be updated to exploit these new features. That was the theory behind Cairo. In practice it never worked out and Cairo wasn't able to fully exploit hardware accelerated rendering. Cairo was very complex so it wasn't easy for the maintainers to keep all the various backends up to date.

Ologn 6y ago

Yes. Oh my goodness, look through the open issues. Look at the pull requests. What is the big O run time of the various functions? Sometimes someone pops in from a university and knows how to improve an algorithm and shrink its runtime, perhaps based on the latest graphics research, perhaps based on old research which was somehow missed.