[cairo] Re: New API: cairo_surface_get_width/height

[Owen Taylor]

On Fri, 2006-06-09 at 08:41 -0700, Carl Worth wrote:

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

I don't understand how this differs from the case we already handle of
fallbacks where we have to read the source.

Really, you simply can't expect read beyond the bounds of the area
currently being exposed. Period. That's true for Windows, it's true for
GTK+ cross-platform. It's even true on OS X if you are rendering 
clipped to some sub-area of the window.

The consequence of that is to do a "blur" operation, you have to

 - Render to a temporary surface
 - Blur to to the final destination

Instead of blurring in-place. As it happens, that's also a limitation of
how pixel shaders work... pixel shaders can read multiple pixels from
multiple sources and combine them in programmable ways, but they only
can combine the result of that with a single destination pixel in a
fixed fashion.

						Owen