> > > 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 _______________________________________________ Xorg-driver-geode mailing list Xorg-driver-geode@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-geode