[cairo] Observations from a newb

[Carl Worth]

On Thu, 8 Nov 2007 23:45:39 +0100, Dirk Schönberger wrote:
> The latter could be done by other means, e.g. cairo_push_group and friends.
> A special call for drawing with a global alpha value seems to be rather
> redundant.

Heh. Fortunately that's not at all what cairo_paint_with_alpha is.

Instead cairo_paint_with_alpha is a convenience function for calling
cairo_mask with an argument that is a pattern with a uniform alpha
value.

And yes, I was just arguing that convenience functions do run the risk
of teaching the wrong models, and this might be exactly what's
happening here.

So, to repeat the fundamental model. In cairo there is a fundamental
drawing operation that combines a source pattern with a mask and then
combines that with the destination surface.

There are five functions in cairo that provide for variations of this
drawing operation. They vary only in how the mask is computed:

	cairo_mask   - User provides explicit mask as pattern
	cairo_paint  - Mask is uniform 100% alpha everywhere
	cairo_fill   - Mask is interior of current path
	cairo_stroke - Mask is interior of the stroke of the current path
	cairo_show_glyphs - Mask is formed from glyph shapes

> The idea to use surfaces for filling/stroking paths seems to be powerfull,
> but a little dangerous. From what I see, there exist the following
> possibilities:
> 
> - a "solid" RGB or RGBA surface - ok
> - a "bitmapped" surface, aka pattern or gradient. Works, but need
> workarounds (you have to create a pattern, and create a surface from the
> pattern (if UI understand the pattern API correctly
> - a "vector pattern" surface - doesn't currently work. A potential usecase
> for metafile surfaces, if they are available some day
> - "impossible" surfaces - I don't think it makes much sense to use say, a
> PDF or a SVG surface as source surface for a fill.

There's no danger anywhere.

In cairo, both the source and the mask are patterns, always.

The various possible pattern types, which you were attempting to
describe above are as follows:

 - Solid patterns

 - Gradient patterns

 - Surface patterns

And all of them work just fine, (including PDF and SVG surfaces as
sources). These work as your imagined "vector pattern" surfaces today,
due to the internal cairo_meta_surface_t which is used in the PDF and
SVG surface implementations.

And yes, we have talked about exposing cairo_meta_surface_t to the
public API. It's a worthwhile thing to do, as it will give the same
capability as a PDF source surface today, (but without all the work of
actually converting the meta surface to a PDF file and streaming it
out when it's finished).

> The last possibility seems to be a case of "wrong abstractions",
> specifically the mixing of surfaces (which are output devices / data sinks),
> and e.g. "patterns", which are input devices / data sources

Yes, surfaces are data sinks, and patterns are data sources. But most
all cairo source surfaces work just fine in surface-based patterns,
(cairo_pattern_create_for_surface). In general, any surface _type_
(image, xlib, svg, ps, pdf, etc.), does provide surfaces that will
function inside patterns. But there are some particular surface
instances that won't work reliably, (such as surface created for an
Xlib Window that may be obscured by another Window at any given
time). Other window systems, (win32 and quartz), might also provide
surfaces with similar limitations.

-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.cairographics.org/archives/cairo/attachments/20071108/311aa718/attachment-0001.pgp