[cairo] cairo_draw_with_xlib API

[Carl Worth]

On Mon, 27 Feb 2006 10:17:01 +1300, Robert O'Callahan wrote:
> OK. I tried to avoid making the patch too invasive until I received some
> positive feedback :-)

Yes, understood.

And if you would be so kind as to keep the mass-renaming as a separate
patch from the new work, that would be greatly appreciated. (And git
might be right handy for this---or maybe StackedGit or pg if you find
those preferable).

> It's useful to distinguish "drawing will be clipped to the surface
> extents" from other kinds of clipping: in that case, when I pass an xlib
> surface through for direct drawing, I don't have to ask my native
> drawing code to clip.

Is there really any savings to making this distinction? If you do set
an entire-surface clip region to your native code that doesn't
actually slow anything down does it? (I've always assumed that cairo
is the only API so messed up that asking for clipping can actually
make things a lot slower.)

>                       But I can do this with a general or even
> xlib-specific API to get the surface extents, so should I just add
> cairo_xlib_surface_get_width/height to my xlibs getters patch instead?

> I don't know how to implement this when a clip path has been specified
> that yields a mask surface, without storing the clip path.

Yes, the clip paths would have to be stored. And I botched the
cairo_copy_clip API above. It would really need to return a set of
paths, not a single path. Each path can have multiple sub-paths that
are unioned, and then the set of paths are intersected. So a single
cairo_path_t can't represent all of that. (Conceivably, it could store
the result, but we don't actually have an intersection operator for
paths in cairo.)

>                                                           In fact, even
> if we have a clip path, it may be impossible to express as a union of
> rectangles.

It does get pretty messy without having path intersection in cairo.

The expected use for this stuff is when the user has only passed in a
list-of-pixel-aligned-rectangle (a "region" let's say) clip anyway,
right? So we could define the clip_as_rectangles operation in a way
that would only be guaranteed to give useful results in such a
case. For example, it could convert each path to its bounding region
and then perform the intersection on those.

Then again, this is the same criteria that determines mask-based
clipping or not. So maybe there would be no point in storing the paths
just to be able to return a result here that would not be accurate nor
likely ever to be desired.

So maybe we do just let the clip_as_rectangles stuff fail in these
cases, (though we'll have to document that in terms of what the user
must do---we can't just say "fails if we happen to be using a mask
internally).

It probably was a mistake to not make a more clear API distinction
between the two uses of cairo_clip, (clip-to-pixel-region
vs. use-path-as-mask-for-subsequent-operations). That causes a nasty
performance trap and also the complications we're facing here.

-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/20060227/a31d339d/attachment.pgp