[cairo] [PATCH] Use the new pixman_glyph_cache_t API that will be in pixman 0.28.0

Behdad Esfahbod behdad at behdad.org
Wed May 30 21:35:14 PDT 2012


On 05/31/2012 12:18 AM, Søren Sandmann wrote:
> Behdad Esfahbod <behdad at behdad.org> writes:
> 
>>> The *current* code - master as of today - doesn't do this, but I do
>>> remember that the code used to do this, and I agree it's the right thing
>>> to do.
>>
>> I see. I see the code is commented out.  Not sure where image show_glyphs is
>> happening these days.
> 
> It eventually ends up in composite_glyphs() in cairo-image-compositor.c.
> If you look at composite_glyphs_via_mask() you'll see that when the mask
> is "upgraded" from a8 to a8r8g8b8, what happens is that first the
> original a8 mask is SRCed to the new mask (basically losing the
> content), and then new glyphs are ADDed directly without a white source.

Right.  So the delicacy was lost when this was written.


> So unless I am totally misreading that code, mixing a8 and a8r8g8b8
> fonts doesn't work with current master.
> 
>>> It's easy enough to fix in the pixman code; the only concern is how
>>> seriously we need to take the Render spec. It does seem to call for the
>>> behavior of directly adding the glyphs, but that behavior is so useless
>>> that I can't imagine how anyone could actually rely on it. So I guess
>>
>> I'm not sure I follow.  What behavior of Render are you referring to?
> 
> The spec for CompositeGlyphs* says:
> 
>     When mask-format is not None, glyphs are rendered in the following
>     way with the effective mask computed in mask-format:
> 
>         tmp = temporary alpha picture
>         Combine (Zero, tmp, tmp, None)
>             for each glyph
>                 Combine (Add, tmp, glyph, None)
>             Combine (op, dst, source, tmp)
> 
> which (a) allows for glyphsets to have a format of a8, and (b) allows
> the mask to have a format of a8r8g8b8, and (c) doesn't say anything
> about white sources.
> 
> On the other hand the spec also doesn't mention component alpha at all,
> and the dst-x and dst-y that it has don't actually exist in the code, so
> I'm not too worried about it. I don't think any sane applications are
> relying on their glyphs being invisible.

I see.  I didn't even know that existed.  Perhaps a good idea to submit a
correction there too.

Thanks for the information.

behdad


More information about the cairo mailing list