[cairo] Re: New API: cairo_surface_get_width/height

Carl Worth cworth at redhat.com
Fri Jun 9 08:41:10 PDT 2006


On Fri, 09 Jun 2006 08:07:07 -0400, Owen Taylor wrote:
> 
> We can list various things that Cairo knows that it might be interesting
> to reveal if someone is drawing with native code:

As usual, Owen, a good summary of the issues.

>  - The list list of backend space integer clip rectangles

This list is what roc's patch goes toward.

>  - Whether there is a clip mask in addition

And I believe his patch does at least indicate the presence of this.

>  - The relationship between Cairo's coordinate space and the underlying
>    backend space clip rectnagles.

This exists with cairo_get_matrix and cairo_surface_get_device_offset. 
So it seems like we're in pretty good shape as far as that goes.

> It's certainly worth pointing out that in the motivating case here,
> the information about inherent clipping is available without adding
> anything to Cairo; given an XID, it's straightforward to say:
> 
>  - What's the GdkDrawable for this XID
>  - Is that a pixmap?
>  - What's the size of the pixmap?
> 
> In fact, since Robert is about to call GDK theme drawing functions,
> he's already done the first step.

OK. So maybe Robert is just fine as far as all this goes. Robert?

> > > 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.

Actually, I want to bring this up again. We can say that some surfaces
are useless as sources, (there's nothing in the cairo documentation to
guide users that way, but I guess we could even say that this is just
a limitation of the underlying display system that the programmer of
said system should understand).

However, given surfaces that are already being used as sources, I
still think the size is an inherent aspect of the surface and
something that cairo should allow to be queried.

So the motivation for this line of thought comes from some other work
that is being done in Mozilla, specifically SVG stuff. Tim Rowley has
been working to properly support SVG masking. Now, for a surface with
both alpha and color, cairo uses only the alpha channel when masking,
while SVG uses the combination of the alpha channel with the intensity
from the color channel. (This always struck me as a somewhat odd
definition but when people recently asked how to go from color to
grayscale in cairo I realized one usage that would come from that
definition.)

So, Tim is looking for a way to implement these SVG semantics using
cairo, given a surface pattern to be used as a mask. The best
suggestion I had was to copy the surface to an image surface so that
its contents could be manually expected. So he needs a way to discover
what size of image surface needs to be created.

And in this case, it's really the surface's size that is needed, (that
is, the bounds of content available to be read) as opposed to
something like a current clip (the bounds beyond which writing to the
surface will be ignored) which might conceivably be smaller on some
systems.

So there's something else to consider.

(Of course, Tim will also need cairo_surface_pattern_get_surface as
well, but that seems much less contentious. And while we're at it, I
suppose we might need color-stop get functions for gradient patterns
and ARGB get functions for solid patterns.)

-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/20060609/ec4ca851/attachment.pgp


More information about the cairo mailing list