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

[Bill Spitzak]

What would be more interesting is the number that use the Render API in 
any mode other than OVER. I think that is so tiny that all operators 
other than OVER could be changed and nobody would notice. This set could 
probably be further reduced by removing all the code that calls the 
operators but assume they work the expected way, such as Cairo itself 
when the version is 11 or higher!

Adding new operators is rather annoying because you can't use the "nice" 
names for the new operators, and thus the history of your mistake stays 
forever by having the users remember a strange new name.

Vladimir Vukicevic wrote:
> 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
>