For Gimp we still use libart for certain operations and we would appreciate it, if we could replace it with Cairo at some point. We still miss functionality though: Libart provides art_svp_render_aa(), which provides a callback based way to get calculated pixel values (fixed point values), but leaves it up to the callback to actually put these pixels in e.g. a bitmap. This enables us to composite the drawing on existing pixel data and removing unwanted antialiasing as well as using our own data structures for the pixels. For cairo this probably could be implemented as a specific backend, which does all the rendering-to-pixels-math, but instead of storing these into a bitmap and handing the bitmap to the application would just invoke callbacks specified by the application.
That would be rather hard to do. Needs major changes in pixman. Isn't rendering to a temp buffer faster? I assume buffers are huge in many gimp uses..
Well, these operations operate on images, which can be potentially huge. The libart rendering interface allows us to operate on a tile by tile basis, which is easier for us than to have to deal with a big temporary buffer which would only be there to be copied into a tile-manager which in a lot of cases is temporary as well. Unfortunately I have no clue about cairo internals, so I cannot really comment on that. Maybe iterating over the gimp-tiles and creating lots of image surfaces and repeatedly drawing translated versions of the stuff to them is fast enough, it just feels like a waste of ressources. However, the callback mechanism would also be useful for Gegl, where we are interested in a >8bit precision and different color spaces. The callback mechanism would allow us to do a custom color conversion on the fly. Hmm. I guess we are about to mix two issues here: a) I'd like to be able to draw parts ("tiles") of an image without having to - store the complete image in a huge buffer - draw the drawing again and again for the next tiles. b) Make it possible for applications to provide custom callback-functions that receive calculated color values and are free to put these into memory in whatever format they need later. If you want to have a look at how gimp uses libart now: the relevant code is in gimp/app/core/gimpscanconvert.c
(In reply to comment #2) > Hmm. I guess we are about to mix two issues here: > > a) I'd like to be able to draw parts ("tiles") of an image without having to > - store the complete image in a huge buffer > - draw the drawing again and again for the next tiles. > > b) Make it possible for applications to provide custom callback-functions > that > receive calculated color values and are free to put these into memory in > whatever format they need later. Yes, those are definitely two different issues. So, is anything missing from cairo for (a)? And for (b) can you provide me anything like a detail of what a callback would look like in terms of cairo's imaging model? I understand that libart provides to a callback a set of run-length encoded alpha values. And that is sufficient for capturing the result of rasterization, but cairo's imaging model includes a lot more than rasterization. When you say "cairo_stroke" you're asking for the path to be rasterized, yes, but also for source pattern to be intersected with that mask and the result to be blended with the destination. How would that all fit into a proposed callback scheme? Meanwhile, I think the issue of "how should cairo be enhanced so that gimp can make good use of it" is extremely interesting. And I also think that bugzilla is an awful place for that discussion, (we have a _lot_ more people reading the cairo mailing list than random bugs in bugzilla). Could you please open this discussion on the cairo mailing list? Thanks, -Carl
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/153.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.