[Xorg-driver-geode] Glitch over text areas

[Martin-Éric Racine]

2012/10/23 Mart Raudsepp <leio at gentoo.org>:
>> > > After a lot of trial and error i got my geode video card working, but
>> > > now i have some kind of glitch over icons and text areas.
>> > >
>> > > My hardware:  PackardBell s18p, also known as: VYE S18 , Kohjinsha
>> > > SA1F00 and other re-branded names of "s18p"
>> > >
>> > >
>> > >
>> > > Example of the glitch: http://i.imgur.com/hD30V.jpg
>> >
>> > I can reproduce this easily as well in firefox and GtkLabels after
>> > having recently upgraded to cairo-1.12. I believe we are suffering from
>> > a similar problem in our driver than even some mainstream ones did[1],
>> > and I meant to make sure we don't after I upgraded to cairo-1.12. Now
>> > that I have, I'll take a closer look on solving this soon.
>> >
>> >
>> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=47266
>>
>> It is indeed quite surely that bug.
>>
>> In summary, cairo-1.12 started using solid pictures instead of 1x1
>> repeated pictures in many cases, including code paths that end up doing
>> glyph rendering.
>>
>> The generic EXA fallback code has still a bug in handling the fallback
>> of those solid pictures in this situation, and in Geode we still
>> fallback it as we do not have hardware acceleration code for this
>> situation (as no-one has yet thought about its implementation, as before
>> cairo-1.12 apparently practically nothing made use of this).
>>
>> So technically the glitch on text areas is the cause of xserver, however
>> in practice we should really try to implement solid pictures now.
>> While xserver should still be fixed to not cause rendering issues if a
>> driver fallbacks on solid picture, we really should get solid pictures
>> acceleration implemented now. It is very important to the performance of
>> text and some other rendering now with cairo-1.12.
>> It should be possible with a 1x1 repeat pattern image in scratch area or
>> so, but there may be even better methods for our hardware - needs
>> research.
>
> I pushed an implementation of this acceleration to git now for the cases
> that matter for text rendering with cairo-1.12.
> Those who are able to - please test from git that this corruption is now
> fixed.
>
>
> As technical details, actually repeating 1x1 sources were already
> implemented via a constant source color, so essentially 1x1R used by
> cairo-1.10 was basically implemented via emulating solid pictures, but
> real solid pictures were not supported before.
>
> Michel has by now also found a likely fix for the fallback path[1], but
> as we want the case accelerated anyway, we don't hit that path anymore
> and shouldn't trigger that bug in existing xserver versions now.
>
> Very quick benchmarking suggests a 3-12% win in cairo-traces benchmarks,
> but I re-run them more properly later on with the other fixes in place
> for a release. (Many of the cairo-traces common benchmarks seem to use
> subpixel smoothing in the text, which fallbacks anyways; mitigating such
> cases is a separate ongoing work)
>
> However before cairo-1.12 wasn't practically usable before on GeodeLX
> due to this misrendering, and now that it is, the performance benefits
> of cairo-1.12 over cairo-1.10 can be leveraged. cairo-1.12 over 1.10 on
> GeodeLX (without this solid pictures improvement) provides a 1.6x..2.2x
> win in some cases even with regular smoothed text rendering ending up
> with some fallbacks before this patch and subpixel smoothed text still
> causing migration overhead.
> So testing with cairo-1.12 in general would be nice. Using normal font
> smoothing (as opposed to subpixel smoothing for LCD screens) is
> suggested for currently best possible performance.

Much better than previously as far as icon rendering in GNOME's
fallback mode, but remains a black square around the mouse pointer
whenever it hovers over the Totem window.

Xserver: 1.12.4
Cairo: 1.12.2

This is on Debian Wheezy running on an LX800-based FIC ION603A.

Greetings,
Martin-Éric