[Xorg-driver-geode] Glitch over text areas

[Mart Raudsepp]

> 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.

I didn't push anything icon rendering related into git yet, that's still
just an attachment on the relevant bug, which I am finishing checking
the last gotcha about very soon and then pushing later today or
tomorrow. So not really sure what you see about icons different there,
maybe just a coincidence in randomness.
After also getting a fix for icons into git (which isn't there yet) I
want to check some SHM image transfer with cairo-1.12.4 (it started
using it only then afaik), write NEWS entries for this stuff, and ask
you to test and release :)

The currently last pushed commit should be only fixing text rendering
corruption in gtk labels, gtk menus, firefox underlined links and such
common places.

Icons are related to GTK3 way of drawing them hitting that particular
bug - as said, this is not yet fixed in git of right now (but very
soon).

> Xserver: 1.12.4
> Cairo: 1.12.2
> 
> This is on Debian Wheezy running on an LX800-based FIC ION603A.