[cairo] [cairo-commit] 2 commits - src/cairo-rtree.c src/cairo-rtree-private.h src/cairo-xlib-surface.c

[Soeren Sandmann]

Carl Worth <cworth at cworth.org> writes:

> If you'd like to fix things, there is more than a comment clean-up
> needed. Here's the problematic bit:
> 
>     /* Render <= 0.10 seems to have a bug with PictOpSrc and glyphs --          
>      * the solid source seems to be multiplied by the glyph mask, and           
>      * then the entire thing is copied to the destination surface,              
>      * including the fully transparent "background" of the rectangular          
>      * glyph surface. */
>     if (op == CAIRO_OPERATOR_SOURCE &&
>         ! CAIRO_SURFACE_RENDER_AT_LEAST(dst, 0, 11))
>     {
>         return UNSUPPORTED ("known bug in Render");
>     }
> 
> Unlike the comment might lead one to believe, the described behavior
> seems to be according to the Render specification. Or perhaps, this is
> an under-specified part of Render. But either way, we don't expect the
> behavior of Render to change.

As far as I can tell, the comment is describing correct Render
behavior. The specification for 

        (src IN glyph) SRC dest

unambiguously calls for copying the alpha channel, including all the
zeros generated by the multiplication, into the destination,
overwriting whatever was there before.

> Later in the function there's a workaround for Render PictOpClear. It
> doesn't have the same Render-version problem, but it also has a comment
> that's perhaps a little less clear than desirable.

That comment is

    /* PictOpClear doesn't seem to work with CompositeText; it seems to ignore
     * the mask (the glyphs).  This code below was executed as a side effect
     * of going through the _clip_and_composite fallback code for old_show_glyphs,
     * so PictOpClear was never used with CompositeText before.
     */

But this is precisely the same issue. Whoever wrote that comment seems
to expect that the effect of render composite operations are bounded
by the mask, but that is not the case. The CLEAR operator clears
everything within the clip, regardless of mask.

If I had a time machine, I certainly would *make* Render respect the
mask in all cases by changing the equation to

        (src OP dest) LERP_mask DEST

so that masks would always be a restriction on the pixels
affected. Aside from being much more useful and corresponding to what
people expect (and what I suspect Keith had in mind), this would also
make component alpha a whole lot simpler to specify, understand, and
implement. However, I don't have a time machine.

If this issue really is the source of confusion, there may be similar
"bugs" for operators such as IN, IN_REVERSE, OUT, ATOP_REVERSE, and
probably others, all of which have in common that if the mask is 0,
the destination will be zero making it appear as if they don't respect
the mask.

And I generally support the idea of fixing bugs and performance issues
in Render and pixman rather than working around them in cairo.


Soren