[Xorg-driver-geode] Glitch over text areas

[Mart Raudsepp]

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



1. http://lists.x.org/archives/xorg-devel/2012-October/034118.html


Best,
Mart Raudsepp