Bug 11379

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.