[cairo] Observations from a newb

[Dirk Schönberger]

> For example, one of the reasons I think it's superior to have the
> idiom:
>  cairo_set_source_surface (cr, image, 0, 0);
>  cairo_paint (cr);

> for the "draw an image" operation over an explicit cairo_draw_image()
> function is that it lends itself toward the user naturally learning
> other operations, such as "draw a cropped rectangle of an image":

>  cairo_set_source_surface (cr, image, 0, 0);
>  cairo_rectangle (cr, x, y, width, height);
>  cairo_fill (cr);

> or "draw an image at 50% opacity":

> cairo_set_source_surface (cr, image, 0, 0);
> cairo_paint_with_alpha (cr, 0.5);

Hmm. I am rather ambivalent on this. The former example I would do with
clipping regions instead, so that the draw image still would be a "terminal
primitive".

 cair_save(cr)
 cairo_rectangle (cr, x, y, width, height);
 cairo_clip (cr);
 cairo_set_source_surface (cr, image, 0, 0);
cairo_paint (cr);
 cairo_restore()

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.

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.

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

Regards
Dirk