3 ms·

Typical hackernews half-off-topic reposte. Not even sure why I bother... > There are times when you absolutely DO want to use image surfaces, such as when you

Typical hackernews half-off-topic reposte. Not even sure why I bother... > There are times when you absolutely DO want to use image surfaces, such as when you need raw access to the pixel data, or if you want to combine cairo rendering with something else. And at that point, you really can't complain about Cairo being slow, can you? You're not even doing vector graphics at this point, you're back in raster graphics territory. Cairo would have been a better library if the image surface was only public in debug builds, forcing developers to learn and understand the implications of using it or reinventing it yourself with some combination of calls that end in XGetImage or XPutImage which has plenty of neon lights around it reminding people that it's slow to do these operations. Literally any raster API that has to download the image from the server, change a pixel, and put the image back on the server is going to be slow. This is precisely why X extensions like Xdamage and Xrender exist to attempt to mitigate the damage by manipulating smaller image regions (less data to download/upload) and pushing operations server-side, and why X APIs like "XPutPixel" exist. But there are limits to just how good these things can ever be; they're going to be limited by GPU-to-main-memory bandwidth and CPU rendering speeds _always_. These raster problems are why UI toolkits have moved on to using OpenGL( ES) and Wayland and similar architectures on other OSes; OpenGL, despite its flaws, makes it very explicit when you're doing obviously slow things like download/modify/upload and has tools that make it easy to avoid the need to do these roundtrips, and Wayland doesn't know so much what a "pixel" is, just how to move buffers around and notionally where those buffers are in space - it's up to the compositor's implementation to figure out how to put together the actual images in buffers and put them on output devices. > It was a looong while since I used cairo so I don't know if my information is correct, And this seems to be the recurring problem... everyone's moved on, cairo's now "infrastructure", nobody gives a damn about infrastructure until it's crumbling, and then it's hard to find anyone to devote resources to repairing and maintaining infrastructure... Luckily, Federico's good at these things, and has historically been good at finding devs to give him a hand. I can't really tell you anything about your pixman patches though, besides the fact that pixman's practically unmaintained too (see my first post about how the devs moved on), it's shared infrastructure with the X server, and nobody really wants to touch it because it's "stable" and was mostly written before the era of unit tests and CI/CD so it's hard to prove changes to it are correct across all of the various platforms and use cases it has to support... It's like trying to change Win32 APIs, only worse because people are still building Xorg on bizarro platforms and architectures you won't have access to test on. Your best bet is to actually bug developers with commit access to review/push your patches and then work your way up to commit access and start actually maintaining this stuff.

bjourne 9y ago
> And at that point, you really can't complain about Cairo being slow, can you? You're not even doing vector graphics at this point, you're back in raster graphics territory. The dichotomy between vector and raster graphics does not exist on screens built using pixels. Eventually whatever you are doing you end up with pixel data. It is incredibly common to require access to this pixel data for some reason. For example, for a long time Cairo used pre-multiplied alpha for alpha compositing which caused all sorts of grief for people who required straight alpha. You idea of Cairo hiding the image data would have made it impossible for use for rendering transparent PNGs as they have (or had, I don't know how Cairo works these day) a pixel format Cairo doesn't support. Or for using cairo with SDL for that matter. Your description of how raster APIs works is wrong. What they do is that they write to an image buffer which is then uploaded to the X server. But if the server has the shm extension, they just write the pixels to a shared buffer. Wayland doesn't impose any rendering API on clients. It gives you a pixel buffer or a GL context and lets you draw whatever you want. TL;DR pure vector graphics does not work. And the sooner you vector weenies realize that, the better. :p

bjourne 9y ago

> And at that point, you really can't complain about Cairo being slow, can you? You're not even doing vector graphics at this point, you're back in raster graphics territory. The dichotomy between vector and raster graphics does not exist on screens built using pixels. Eventually whatever you are doing you end up with pixel data. It is incredibly common to require access to this pixel data for some reason. For example, for a long time Cairo used pre-multiplied alpha for alpha compositing which caused all sorts of grief for people who required straight alpha. You idea of Cairo hiding the image data would have made it impossible for use for rendering transparent PNGs as they have (or had, I don't know how Cairo works these day) a pixel format Cairo doesn't support. Or for using cairo with SDL for that matter. Your description of how raster APIs works is wrong. What they do is that they write to an image buffer which is then uploaded to the X server. But if the server has the shm extension, they just write the pixels to a shared buffer. Wayland doesn't impose any rendering API on clients. It gives you a pixel buffer or a GL context and lets you draw whatever you want. TL;DR pure vector graphics does not work. And the sooner you vector weenies realize that, the better. :p