5 ms·

Helping Cairo, the rendering library

123 points by buovjaga 9y ago

dmm 9y ago
> But some tests, I have no idea what changed that made them break. Michael Feathers in "Working Effectively with Legacy Code" defines a unit test as a test with two qualities: 1. It runs fast (1ms is slow for a unit test) 2. Has excellent locality, so when a test fails it's obvious what code broke it From my experience fixing sparc64 package builds for Debian the second quality is hard to get right. Many times I would encounter a test failure that was the result of a complicated chain of function calls and it wasn't obvious what was broken. When I was fixing the gtk build I discovered their codebase is sprinkled with ASSERTs which turned out to be SUPER useful, particularly because they communicated exactly where a precondition wasn't holding up. Previously I was never that interested in asserts but that experience makes me want to look into them again.
- makmanalp 9y ago
  On the flipside the reason excellent locality usually doesn't happen is that the narrower the scope of your tests are (think on the spectrum of integration tests to unit tests), the likelier that they are highly coupled with implementation details that might change, making tests brittle and refactoring harder. Or you go the full java style strategy-pattern-dependency-injection-abstractsingletonproxyfactorybean route to get both locality and ease of changing behavior, but then you're now building these complex class hierarchies and doing anything takes a lot more effort and boilerplate. Now changing behavior is easy but changing architecture is hard. It's a tough tradeoff, really. I'm not saying we don't need one or the other, but it's more of a case by case judgement call that folks would like to admit IMHO.
- sciurus 9y ago
  Assuming the tests ever passed, git-bisect should make it possible to find the commits that broke them. This is tedious and time-consuming (particularly if the build and test cycle is slow) but it can be automated. https://lwn.net/Articles/317154/ https://lwn.net/Articles/317154/
- jabot 9y ago
  To be fair, the original article does not contain the word "unit" - it just talks about tests, which is arguably more general. In my personal opinion, tests that are "non-unit" tests are still useful - testing the validity and correct functioning of larger pieces of software is a good thing, even if it does not run fast, or if the broken code is not immediately obvious.
- jononor 9y ago
  With continious integration (CI) one gives excellent locality in time/changesets. So I think the locality argument might not be as important today. Though I am biased, since I generally prefer to have tests that exercise more code, normally only against external APIs. Strong agreement on that pre/post-condition/invariants are highly useful though. I prefer that they are enabled also in production code, except for in the hottest of codepaths.
stuaxo 9y ago
Cairo is a library that has a great balance between the simplicity of it's abstractions and the power it gives you. Christoph Reiter has been doing some great work to revive and update the python bindings. https://github.com/pygobject/pycairo/ https://github.com/pygobject/pycairo/ I'd also like to point out Cairo generally has a friendly mailinglist, and is quite a fun library to make graphics with.
kjksf 9y ago
Unfortunate reality is that Cairo project doesn't want to be helped. I've been checking Cairo from time to time for a very long time. There was a period of active development because it was used by FireFox and, I think, had at least one dev working on it paid by Intel. But there's no indication that the project wants your help. See https://www.cairographics.org/ https://www.cairographics.org/ and try to find the part that tells you how to submit a patch. To submit a bug you need to use a mailing list or antiquated bugzilla instance. Cairo is ostensibly a Gnome-affiliated project as it's used in Gtk. Federico is a big deal in Gnome project. It's telling that he had to setup up essentially a personal fork of Cairo on gitlab to do any work. At this point in time, moving the code officially to GitHub (or GitLab) from anongit.freedesktop.org should be a no brainer if your goal is to have contributors.
- le-mark 9y ago
  Do you think it's reasonable someone would have said the same thing about moving to sourceforge or google code, and how that would have been a bad idea? The reality is services such as this are ultimately ephemeral, and out all the ephemeral things one may want to manage, email and mailing lists maybe the lowest common denominator.
  - mnem 9y ago
    Google Code and and Sourceforge were around for, what, 10 years or so? That would be 10 years of potentially greater levels of contribution. IMO, that's a price worth paying for moving a repo once a decade. Everything is ephemeral. Take advantage of it while it makes sense for whatever it is that you're trying to achieve.
- tetromino_ 9y ago
  You are claiming that Cairo doesn't want to be helped, but your actual complaint seems to be that Cairo uses a development workflow that you personally dislike and see as old-fashioned.
  - Xylakant 9y ago
ksherlock 9y ago
The proposed c++ 2d graphics standard is based on Cairo. http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0267r7.pdf http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0267r7.... "The reference implementation of this paper provides a software implementation of the math and rendering support classes. This is based on the Cairo library; indeed, so far the reference implementation has been based on Cairo. However, it is now possible to provide an implementation more appropriate to the target platform."
- sparkie 9y ago
  I think the committee will (and should) throw this proposal out of the window. Most of the notable C++ projects are already using Skia.
speps 9y ago
The problem with Cairo is that it's painfully slow. Last time I tried, I don't remember what it was exactly but it just couldn't cope with realtime performance.
- awalton 9y ago
  > The problem with Cairo is that it's painfully slow. It really isn't though... it's just painfully easy to fall onto slow paths, and not obvious how not to. Time and again I've seen people stack benchmarks of cairo where they're only benchmarking the image surface; of course that's slow, it's CPU rendering! If your realtime graphics app is ever creating a new surface and it's not using cairo_surface_create_similar() or cairo_{xlib,xcb}_surface_create(), you've probably fucked up. Nearly 100% of the time, when someone's fallen into a slow path using cairo, it's because they've managed to get cairo to copy something back from the graphics server, do some operations on the CPU, and then reupload back to the server. And surprise, that's very slow. After that, the majority of remaining slow cases are due to creating too many clipping regions (which is common in lots of complex rendering applications, but usually caught by the application developers themselves since Cairo's actually remarkably good at debugging these kinds of rendering issues with tools like the script surface and cairo-perf-trace). Meanwhile, Firefox has managed to pretty much stamp out all of the rest of the actual painfully slow Cairo paths... Part of this perceived slowness in Cairo is because the example code is pretty bleak and abysmal (just look at https://www.cairographics.org/documentation/ https://www.cairographics.org/documentation/ if you don't believe me), part of it is because everyone who used to maintain cairo (before they ran off and are now doing VR at Valve, or Wayland, or Tizen, or whatever) were Xorg developers and Xorg things were "so trivially obvious" to them that isn't trivially obvious to... basically everyone else, and part of it is because of "stack-overflow-itis" - "I'm just going to copy this example code because this guy got it working and I don't care to understand the mechanics of how/why it works/why it's slow in my code." tl;dr: cairo's not slow, stop creating/rendering against image surfaces, use the perf tools to keep clear of bad application behaviors.
  - yetihehe 9y ago
    Yeah, I was actually surprised at how fast cairo can be. I had some ideas as to optimize things like prerender map markers into some tiles and then render those tiles, but it seems for my use case (rendering less than 10k small images on single surface) I didn't even need to optimise it, with 2k images I had over 40fps which felt more snappy than google maps, which was enough. Of course if someone needs something better, hw accelerated opengl is the way to go. Current processors are fast, but they have their limits.

123 points by buovjaga 9y ago

dmm 9y ago

> But some tests, I have no idea what changed that made them break. Michael Feathers in "Working Effectively with Legacy Code" defines a unit test as a test with two qualities: 1. It runs fast (1ms is slow for a unit test) 2. Has excellent locality, so when a test fails it's obvious what code broke it From my experience fixing sparc64 package builds for Debian the second quality is hard to get right. Many times I would encounter a test failure that was the result of a complicated chain of function calls and it wasn't obvious what was broken. When I was fixing the gtk build I discovered their codebase is sprinkled with ASSERTs which turned out to be SUPER useful, particularly because they communicated exactly where a precondition wasn't holding up. Previously I was never that interested in asserts but that experience makes me want to look into them again.

makmanalp 9y ago
On the flipside the reason excellent locality usually doesn't happen is that the narrower the scope of your tests are (think on the spectrum of integration tests to unit tests), the likelier that they are highly coupled with implementation details that might change, making tests brittle and refactoring harder. Or you go the full java style strategy-pattern-dependency-injection-abstractsingletonproxyfactorybean route to get both locality and ease of changing behavior, but then you're now building these complex class hierarchies and doing anything takes a lot more effort and boilerplate. Now changing behavior is easy but changing architecture is hard. It's a tough tradeoff, really. I'm not saying we don't need one or the other, but it's more of a case by case judgement call that folks would like to admit IMHO.
sciurus 9y ago
Assuming the tests ever passed, git-bisect should make it possible to find the commits that broke them. This is tedious and time-consuming (particularly if the build and test cycle is slow) but it can be automated. https://lwn.net/Articles/317154/ https://lwn.net/Articles/317154/
jabot 9y ago
To be fair, the original article does not contain the word "unit" - it just talks about tests, which is arguably more general. In my personal opinion, tests that are "non-unit" tests are still useful - testing the validity and correct functioning of larger pieces of software is a good thing, even if it does not run fast, or if the broken code is not immediately obvious.
jononor 9y ago
With continious integration (CI) one gives excellent locality in time/changesets. So I think the locality argument might not be as important today. Though I am biased, since I generally prefer to have tests that exercise more code, normally only against external APIs. Strong agreement on that pre/post-condition/invariants are highly useful though. I prefer that they are enabled also in production code, except for in the hottest of codepaths.

stuaxo 9y ago

Cairo is a library that has a great balance between the simplicity of it's abstractions and the power it gives you. Christoph Reiter has been doing some great work to revive and update the python bindings. https://github.com/pygobject/pycairo/ https://github.com/pygobject/pycairo/ I'd also like to point out Cairo generally has a friendly mailinglist, and is quite a fun library to make graphics with.

kjksf 9y ago

Unfortunate reality is that Cairo project doesn't want to be helped. I've been checking Cairo from time to time for a very long time. There was a period of active development because it was used by FireFox and, I think, had at least one dev working on it paid by Intel. But there's no indication that the project wants your help. See https://www.cairographics.org/ https://www.cairographics.org/ and try to find the part that tells you how to submit a patch. To submit a bug you need to use a mailing list or antiquated bugzilla instance. Cairo is ostensibly a Gnome-affiliated project as it's used in Gtk. Federico is a big deal in Gnome project. It's telling that he had to setup up essentially a personal fork of Cairo on gitlab to do any work. At this point in time, moving the code officially to GitHub (or GitLab) from anongit.freedesktop.org should be a no brainer if your goal is to have contributors.

le-mark 9y ago
Do you think it's reasonable someone would have said the same thing about moving to sourceforge or google code, and how that would have been a bad idea? The reality is services such as this are ultimately ephemeral, and out all the ephemeral things one may want to manage, email and mailing lists maybe the lowest common denominator.
- mnem 9y ago
  Google Code and and Sourceforge were around for, what, 10 years or so? That would be 10 years of potentially greater levels of contribution. IMO, that's a price worth paying for moving a repo once a decade. Everything is ephemeral. Take advantage of it while it makes sense for whatever it is that you're trying to achieve.
tetromino_ 9y ago
You are claiming that Cairo doesn't want to be helped, but your actual complaint seems to be that Cairo uses a development workflow that you personally dislike and see as old-fashioned.
- Xylakant 9y ago

ksherlock 9y ago

The proposed c++ 2d graphics standard is based on Cairo. http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0267r7.pdf http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0267r7.... "The reference implementation of this paper provides a software implementation of the math and rendering support classes. This is based on the Cairo library; indeed, so far the reference implementation has been based on Cairo. However, it is now possible to provide an implementation more appropriate to the target platform."

sparkie 9y ago
I think the committee will (and should) throw this proposal out of the window. Most of the notable C++ projects are already using Skia.

speps 9y ago

The problem with Cairo is that it's painfully slow. Last time I tried, I don't remember what it was exactly but it just couldn't cope with realtime performance.

awalton 9y ago
> The problem with Cairo is that it's painfully slow. It really isn't though... it's just painfully easy to fall onto slow paths, and not obvious how not to. Time and again I've seen people stack benchmarks of cairo where they're only benchmarking the image surface; of course that's slow, it's CPU rendering! If your realtime graphics app is ever creating a new surface and it's not using cairo_surface_create_similar() or cairo_{xlib,xcb}_surface_create(), you've probably fucked up. Nearly 100% of the time, when someone's fallen into a slow path using cairo, it's because they've managed to get cairo to copy something back from the graphics server, do some operations on the CPU, and then reupload back to the server. And surprise, that's very slow. After that, the majority of remaining slow cases are due to creating too many clipping regions (which is common in lots of complex rendering applications, but usually caught by the application developers themselves since Cairo's actually remarkably good at debugging these kinds of rendering issues with tools like the script surface and cairo-perf-trace). Meanwhile, Firefox has managed to pretty much stamp out all of the rest of the actual painfully slow Cairo paths... Part of this perceived slowness in Cairo is because the example code is pretty bleak and abysmal (just look at https://www.cairographics.org/documentation/ https://www.cairographics.org/documentation/ if you don't believe me), part of it is because everyone who used to maintain cairo (before they ran off and are now doing VR at Valve, or Wayland, or Tizen, or whatever) were Xorg developers and Xorg things were "so trivially obvious" to them that isn't trivially obvious to... basically everyone else, and part of it is because of "stack-overflow-itis" - "I'm just going to copy this example code because this guy got it working and I don't care to understand the mechanics of how/why it works/why it's slow in my code." tl;dr: cairo's not slow, stop creating/rendering against image surfaces, use the perf tools to keep clear of bad application behaviors.
- yetihehe 9y ago
  Yeah, I was actually surprised at how fast cairo can be. I had some ideas as to optimize things like prerender map markers into some tiles and then render those tiles, but it seems for my use case (rendering less than 10k small images on single surface) I didn't even need to optimise it, with 2k images I had over 40fps which felt more snappy than google maps, which was enough. Of course if someone needs something better, hw accelerated opengl is the way to go. Current processors are fast, but they have their limits.