EXA glyph corruption

[Maarten Maathuis]

On Thu, Aug 28, 2008 at 9:01 PM, Daniel Drake <dsd at laptop.org> wrote:
> Hi,
>
> I'm working on OLPC's upcoming software release, including an update
> from Fedora 7 to Fedora 9. Fedora 9 ships xserver 1.4.99.906.
>
> Unfortunately, we encounter a rendering bug with one of our applications
> (etoys). Certain components that move around the screen render badly
> (leave trails, etc) when interacting with the mouse cursor.
> http://dev.laptop.org/ticket/7612
>
> An etoys developer narrowed this down to a small program to reproduce
> the issue:
> http://dev.laptop.org/attachment/ticket/7612/sqcursortest.c
>
> It moves a green square around the screen. If you let the green square
> move onto the mouse cursor, you get graphical corruption. See
> http://dev.laptop.org/~dsd/20080822/xshm-bug.png for a screenshot - the
> mouse cursor didn't get included in the screenshot, but it is in the
> white area inside the green square. The square should be solid green
> even with the mouse cursor on top.
>
> I noticed that Fedora recently added an "exa master upgrade" patch to
> their xserver test builds - backporting the most recent EXA code from
> master. Decided to give this a try in hope that it solves the bug.
> Here is the patch:
> http://dev.laptop.org/~dsd/20080822/xserver-1.4.99-exa-master-upgrade.patch
>
> The good news is that it solves the bug, here is a new screenshot:
> http://dev.laptop.org/~dsd/20080822/xshm-bug-fixed.png
> The mouse cursor is on top of the green square in that screenshot with
> no rendering glitches.
>
> The bad news is that text rendering is now quite badly broken:
> http://dev.laptop.org/~dsd/20080822/text-not-ok.png
> with the older X server build, that same screen looks like:
> http://dev.laptop.org/~dsd/20080822/text-ok.png
>

Getting your glyphs cut off is a "known" bug, on CURRENT master it
appears when you provide a composite implementation (then it enables
the glyph cache, previously it enabled it unconditionally), but
fallback at some stage during font rendering.

If provide a composite implementation, then i guess you don't support
rendering onto PICT_a8 surfaces (or PICT_A8 pixmaps at all)?

Maarten.

> I backported the updated exa code from master again, this didn't help.
>
> Jordan Crouse (geode driver author) also had a look at the text
> corruption. He thinks that EXA might be passing him the wrong glyph
> mask:
>
> < CosmicPenguin> It looked to me based on whatever tag I was compiling
>                 against the other day that the mask I was getting was
>                 wrong
> < CosmicPenguin> I only did enough work to verify that the driver was
>                 rendering correctly
> < CosmicPenguin> keep in mind that I may or may not be missing
>                fontconfig or other support software for fully
>                effective font fun
> < CosmicPenguin> I am not sure at what point from file to screen the
>                 font
>                  was being mismanaged - all I know is that I was doing
>                  whatever I was told
> < CosmicPenguin> and thats not half bad
>
>
> Any ideas?
> We know that whatever caused the regression is some part of this patch:
> http://dev.laptop.org/~dsd/20080822/xserver-1.4.99-exa-master-upgrade.patch
>
> Thanks,
> Daniel
>
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>