[cairo] Unbounded source operators in the backends

Owen Taylor otaylor at redhat.com
Sat Aug 6 11:04:27 PDT 2005


The revised clipping patch I'm working on deals primarily with the 6
"unbounded" operators:

SOURCE, CLEAR, IN, OUT, DEST_IN, DEST_ATOP

These are the operators that have an effect even where the mask or
source are transparent.

It turns out that beyond the clipping equation there are a whole 
slew of problems with the implementation of these operators:

A few of them:

- RenderCompositeGlyphs and RenderCompositeTrapezoids create 
   temporary masks that are the size of the bounds of the 
   glyphs or trapezoids and only composite that area. 

- The implementation of RenderComposite clips untransformed
   rendering to the intersection of the source and the mask.

   [ The RenderCompositeTrapezoids and RenderComposite problems
     also occur in the corresponding pixman functions ]

- _cairo_ft_scaled_font_show_glyphs() assumes that it is
   possible to composite each glyph individually and get the
   same result as compositing them all at once.

As always, we could attack these problems at multiple levels:

1) The cairo_gstate() code could avoid triggering these problems
   by always, when rendering with an unbounded operator, generating
   a full-size source copy, and a full-size mask and then 
   only calling _cairo_surface_composite() on these.

2) We could fix and work around the problems backend-by-backend
   in cairo.

3) We could consider these to be problems to be fixed in the
   underlying libraries and servers.

My feeling is that 2) is the appropriate level to work at
(while filing bugs for 3) so that the problems aren't forgotten).
1) would be simpler to code, but also increases the overall
complexity of the gstate => surface interface by adding more
special conditions.

A related question is the interpretation of width, height
in:

cairo_private cairo_status_t
_cairo_surface_composite_trapezoids (cairo_operator_t   operator,
                                     cairo_pattern_t    *pattern,
                                     cairo_surface_t    *dst,
                                     int                src_x,
                                     int                src_y,
                                     int                dst_x,
                                     int                dst_y,
                                     unsigned int       width,
                                     unsigned int       height,
                                     cairo_trapezoid_t  *traps,
                                     int                ntraps);

cairo_private cairo_status_t
_cairo_surface_show_glyphs (cairo_scaled_font_t         *scaled_font,
                            cairo_operator_t            operator,
                            cairo_pattern_t             *pattern,
                            cairo_surface_t             *surface,
                            int                         source_x,
                            int                         source_y,
                            int                         dest_x,
                            int                         dest_y,
                            unsigned int                width,
                            unsigned int                height,
                            const cairo_glyph_t         *glyphs,
                            int                         num_glyphs);

Currently they act as "hints" - the backend is allowed to assume that
the glyphs or trapezoids, once they have been clipped by any clip region
set on the surface, don't extend outside the rectangle 
[dst_x, dst_y, width, height], but once we add unbounded operators into
the picture, things get more complicated, since we have to know 
how far to extend the operation.

Can we stop at the edges of the rectangle, or do we need to paint all 
the way out to the surface clip? My feeling is that the first
interpretation is the right one - it is consistent with how 
width, height work for:

cairo_private cairo_status_t
_cairo_surface_composite (cairo_operator_t      operator,
                          cairo_pattern_t       *src,
                          cairo_pattern_t       *mask,
                          cairo_surface_t       *dst,
                          int                   src_x,
                          int                   src_y,
                          int                   mask_x,
                          int                   mask_y,
                          int                   dst_x,
                          int                   dst_y,
                          unsigned int          width,
                          unsigned int          height);

In other words, composite_glyphs(), composite_trapezoids() are
just providing alternate representations for 'mask', and otherwise
should work just like composite().

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050806/c8265eb5/attachment.pgp


More information about the cairo mailing list