[cairo] Re: New API: cairo_surface_get_width/height

[Carl Worth]

On Thu, 08 Jun 2006 23:14:03 -0400, Owen Taylor wrote:
> 
> What's the motiviation here?

I definitely should have established that better. Robert O'Callahan
has been working on some code in Mozilla that has to cleanly deal with
non-cairo-based rendering to the same underlying objects that Mozilla
is drawing to with cairo, (think browser plugins). In general, I think
we're not handling this really well in cairo right now, (we've got
mark_dirty and flush but those are only parts of what a full handshake
between cairo and non-cairo drawing would entail).

Anyway, the details of what he has been doing can be seen here:

http://lists.freedesktop.org/archives/cairo/2006-February/006402.html
http://lists.freedesktop.org/archives/cairo/2006-February/006442.html
http://lists.freedesktop.org/archives/cairo/2006-March/006527.html
http://lists.freedesktop.org/archives/cairo/2006-May/007006.html

But to summarize, he's working to establish a clip on the underlying
object, (for the sake of the non-cairo drawing), to represent the
clipping that's in place in the current cairo context. So he's been
cooking up a patch to extract the current list of clip rectangles (if
available).

He has also proposed a cairo_has_clip predicate to distinguish the
case of clipping due to a call to cairo_clip() from clipping due to
the inherent limitations of the surface itself, (its "size" or else
some external clipping that is imposed on it).

I balked at the original proposal for cairo_has_clip as seen below:

 On Mon, 27 Feb 2006 10:17:01 +1300 Robert O'Callahan wrote:
 >On Fri, 2006-02-24 at 12:32 -0800, Carl Worth wrote:
 > >On Thu, 23 Feb 2006 16:39:14 +1300, Robert O'Callahan wrote:
 > > > +cairo_public cairo_bool_t
 > > > +cairo_has_clip (cairo_t *cr);
 > > 
 > > Hmm... there's always a clip. Initially it can be thought of as either
 > > an infinitely large rectangle, (which is rather hard to represent), or
 > > else it's a single rectangle no larger than the surface. We can always
 > > return the single rectangle for the case when cairo_clip has never
 > > been called, so do you actually need this function?
 > 
 > 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. 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?

So, I'm already arguing there from the point-of-view of a surface
having a "size". We can just as easily talk about the surface not
having a size per se, but definitely having some limit on the
coordinate values that will have an effect on it, (due to some "clip"
on the underlying surface). Either way, Robert sees some benefit from
being able to distinguish that from cairo_clip()-based clipping, so
I'm looking for a way to advertise it.

So that's what I'm trying to do with cairo_surface_get_width/height.

What proposal would you make instead?

> I don't think the argument about pattern sources is very compelling,
> because using a window as a repeating pattern source is pretty much
> nonsensical, for X, for Windows, or for any system. 

Fine, we can ignore that argument.

> If the desire is simply to push the get size operations up the stack
> to have them in a more logical place, then why not make the operation
> optional and document that not all surfaces have a size?

Your size-less win32 windows still have limits due to the underlying
clipping, right? And that's what GetClipBox reports?

I don't see how that notion wouldn't be captured in get_width/height.
(Obviously, get_width/height isn't providing as detailed information
as it could---we could actually return a rectangle or a list of
rectangles for the "inherent clipping" on a surface, but I don't see
much use in providing an abstraction that detailed.)

> GetClipBox definitely doesn't return the size of the surface, it 
> returns the box that it is interesting to draw on.

So that sounds like that would satisfy what Robert needs. Do you think
we could get by with just changing the wording of the documentation
(and perhaps tweaking the names) of my surface_get_width/height?

-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/20060608/f315fe7a/attachment.pgp