[cairo] recursive quad-tree, or bounding box of changed area during drawing?

[Carl Worth]

On Sun, 04 Jun 2006 03:54:07 +0200, Leon Woestenberg wrote:
>
> This thread has run off in a different direction considering 
> optimization of performance of the software above the interface (I am 
> aware there is much to be done there, but it is irrelevant to what I 
> asked) and X (which is not what I use).

Sorry about that. The thread has drifted into some independently
interesting stuff, but I apologize for not directly answering your
question. I'll attempt that quickly now.

On Wed, 31 May 2006 00:41:57 +0200, you said:
> > Can cairo (or pixman) be queried in similar fashion?

No, nothing like this exists currently.

> > If not, can intimi introduce me to the point where I could introduce
> > such code?
> > 
> > I can think of two ways:
> > - keep track of this in the vector representation (just before actually
> > drawing).

This seems like the right place to do things, but I would suggest that
this is best done at the level above cairo that is passing data to
cairo.

Within cairo there is no persistent state stored about objects being
drawn. But in a canvas or a similar layer above cairo, there can be
persistent state saved about objects, their bounds, their
intersections, etc. which allows for the kind of information you're
looking for to be manipulated and provided much more
efficiently. Plus, that information is useful for other things anyway,
(layout, hit detection, etc.) so is likely to be there already.

> > - keep track of this in the pixel map writeout in pixman (which would
> > introduce overhead at each pixel write access, very undesirable
> > AFAICS).

There is a place in cairo for reasoning about the bounds affected by
each drawing operation. For example, we'll be adding some structure
for computing this for the paginated backends (PS, PDF, and SVG) where
we want to emit image fallbacks for the minimally necessary regions.

Without that all existing yet, I'm not sure whether it will make sense
to unconditionally compute, store, and make that information available
through the public API. We can revisit that later.

But another thing that might make sense is for you to write a thin
cairo backend that builds on top of the image backend, say, and adds
support for these minimal blits to your final destination surface.

So that's at least one other option for you to consider.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060605/994d1841/attachment.pgp