I upgraded my fedora rawhide system to xorg 7.2, and text rendering performance went to hell. EXA and XAA are equally affected. This is the performance I now get from "x11perf --aa24text --rgb24text": XAA: 8000000 trep @ 0.0033 msec (304000.0/sec): Char in 30-char aa line (Charter 24) 320000 trep @ 0.0764 msec ( 13100.0/sec): Char in 30-char rgb line (Charter 24) 96000 trep @ 0.2853 msec ( 3500.0/sec): Char in 30-char rgb core line (Charter 24) EXA: 9600000 trep @ 0.0030 msec (331000.0/sec): Char in 30-char aa line (Charter 24) 4800000 trep @ 0.0063 msec (160000.0/sec): Char in 30-char rgb line (Charter 24) 480000 trep @ 0.0636 msec ( 15700.0/sec): Char in 30-char rgb core line (Charter 24) Previously, this system had these numbers: (taken from bug 4668): XAA: 8000000 trep @ 0.0032 msec (313000.0/sec): Char in 30-char aa line (Charter 24) 320000 trep @ 0.0810 msec ( 12300.0/sec): Char in 30-char rgb line (Charter 24) 320000 trep @ 0.0810 msec ( 12300.0/sec): Char in 30-char rgb core line (Charter 24) EXA: 8000000 trep @ 0.0033 msec (303000.0/sec): Char in 30-char aa line (Charter 24) 4800000 trep @ 0.0063 msec (159000.0/sec): Char in 30-char rgb line (Charter 24) 4800000 trep @ 0.0063 msec (159000.0/sec): Char in 30-char rgb core line (Charter 24) As you can see, the aa and rgb paths are unaffected, but rgb core has degraded by up to a factor ten. (adding anholt as cc as he was the one messing with this the last time.)
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
(In reply to comment #0) > I upgraded my fedora rawhide system to xorg 7.2, and text rendering performance > went to hell. EXA and XAA are equally affected. I don't agree, I've ubuntu and both with a clean 7.2 server, and with the ubuntu (feisty) patched one I get text rendering problems ONLY on _EXA_. XAA works fine (as before). Bye.
Do you have some numbers?
(In reply to comment #3) > Do you have some numbers? It's hard to say (or just find them)... The fact is that all is absolutely slower, but I couldn't find a way to report something... Logs seem normal.
Is this still an issue as of xserver 1.3? Also, is that operation really used for text rendering using the RENDER extension?
Yes, the problem is still there. As for the operation being used, I have no idea. I've just noticed that these tests have a good correlation to the general perceived speed.
(In reply to comment #6) > Yes, the problem is still there. And still with XAA as well as with EXA? If so, can you try and bisect the change that caused it? If not, do different values for Option "MigrationHeuristic" make a difference?
The problem is still present for both XAA and EXA. Bisecting isn't that easy as the server tested is the one Fedora packages. I take it you do not see this difference on your system?
(In reply to comment #8) > Bisecting isn't that easy as the server tested is the one Fedora packages. I don't see the problem. Start the bisect process using the tags/commits corresponding (as closely as possible) to the Fedora versions.
The problem is that building that thing is far from "./configure; make": checking for XORGCFG_DEP... configure: error: Package requirements (xkbui >= 1.0.2 xkbfile xxf86misc xxf86vm xaw7 xmu xt xpm xext x11) were not met: No package 'xkbui' found Can't find a single mention in the fedora repos about xkbui, so I don't know what is going on here.
Option "MigrationHeuristic" "greedy" solves this bug for me. What about you?
> --- Comment #11 from Nicolò Chieffo <84yelo3@gmail.com> 2008-03-27 11:05:57 PST --- > Option "MigrationHeuristic" "greedy" > solves this bug for me. What about you? > That's a workaround, not a fix...
reopening...
I'm not sure what to do about this report, but I think it should at least no longer be a release blocker... First of all, the rendering method used by the test in question is only used by Xft when the RENDER extension is not available or its use is disabled via configuration (or by the app). Neither should be the case normally, so I don't think this can explain or be representative of a general performance issue. Also, as this method works by pulling the drawable contents to the client side, compositing the glyphs over it there in software and then pushing the result back to the server, I'm not sure how it could ever have been this fast...
(In reply to comment #14) > I'm not sure what to do about this report, but I think it should at least no > longer be a release blocker... > > First of all, the rendering method used by the test in question is only used by > Xft when the RENDER extension is not available or its use is disabled via > configuration (or by the app). Neither should be the case normally, so I don't > think this can explain or be representative of a general performance issue. > > Also, as this method works by pulling the drawable contents to the client side, > compositing the glyphs over it there in software and then pushing the result > back to the server, I'm not sure how it could ever have been this fast... Wow. Yeah, moving to 7.5 since I agree this isn't a blocker, and then probably going to WONTFIX it once we look at 7.5.
yeah, doesn't exactly sound critical for 7.5, or indeed any release.
Is this still an issue with recent git?
I'm afraid I don't have this system anymore. I cannot reproduce it on my current machine though.
Resolving per comment #18.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.