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

[Vladimir Vukicevic]

I don't know that there's necessarily dismissal, but it seems like 
changing the mask handling could be done as an additional set of new 
operators, while slowly deprecating the old ones.  Also, other than Xft, 
Cairo, and I presume Qt, are there many direct consumers of the Render 
API?  I guess there may be a good number that use glyph rendering, and 
very few that use traps/etc.

     - Vlad

On 7/28/09 9:30 AM, Bill Spitzak wrote:
> I would think it would help a LOT if Render was changed to match Cairo.
>
> Cairo survived being changed to these new rules. I would think nobody
> is relying on the old behavior because of it's useless or
> unexpectedness, and also because the old behavior can be replicated by
> using the mask as the source. So I don't see why there is there seems
> to be this dismissal of making an incompatible change to Render.
>
> On Jul 27, 2009, at 11:35 PM, Soeren Sandmann wrote:
>
>> 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
>> _______________________________________________
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo