Bitmap font rendering in gtk applications is slow with Cairo 1.12.0-1 and 2. For example gvim and Dina (font) leads to slow build-up of the screen compared to qvim (qt) or gvim with a ttf font. The same problem also occurs for xfce-terminal, but not in urxvt. In htop it shows that xorg goes to high cpu load when making changes on the screen. With cairo-xcb 1.10.2 from AUR (arch user repositories) this problem does not occur. Steps to reproduce: Opening gvim with a bitmap font like Dina, shows a slow buildup of the screen. Also making changes like toggling NERDtree or adding or removing menu toolbars are slow. It is also visible when switching to a desktop with gvim open. The problem is more obvious when the app window is larger. Perhaps the general section is not the right place, but I did not know which backend this might be related to.
This is a driver bug; please attach your Xorg.log.
Hi, I will add it on Tuesday. At the moment I don't have access to my pc.
Created attachment 59715 [details] My Xorg log.
Looks like we may have an issue in the current nvidia driver, they'll want to know about that. Can you please record a trace of working in gvim with your bitmap font using: $ cairo-trace --profile gvim # do stuff, then quit And let's hope the trace is less than 3MiB so it can be attached! Then can you compare the performance using (will need to uncompress the trace first): $ CAIRO_TEST_TARGET=image,xlib perf/cairo-perf-trace -i6 gvim.trace
Created attachment 59737 [details] strace output I ran the command and resized the window two or three times so it has to rebuild the screen a few times and I toggled NERDTree. The other thing I will check in a bit, it seems I don't have this perf/cairo-perf-trace, I will check if the AUR package has it.
Ok, a quick comparison between your trace and the one already in the cairo-traces shows that nvidia has a similar slow-down compared to the image backend for both. As such I think they are already aware of the issue, though possibly not quite aware of how much it impacts upon gvim usability.
[perf] CAIRO_TEST_TARGET=image,xlib ./cairo-perf-trace -i6 ~/gvim.trace [ # ] backend test min(s) median(s) stddev. count [ # ] image: pixman 0.24.4 [ 0] image gvim 0.067 0.067 0.41% 5/6 [ 0] xlib gvim 4.129 4.130 0.55% 5/6 This is the output I get from cairo-perf-trace. It all doesn't mean much to me, but I hope it helps.
Ouch, that's even worse than on my machine. Basically it says that the driver is about 70 times slower than the CPU in this test. No wonder you can see it redraw!
[perf] CAIRO_TEST_TARGET=image,xlib ./cairo-perf-trace -i6 ~/gvim1.trace [ # ] backend test min(s) median(s) stddev. count [ # ] image: pixman 0.24.4 [ 0] image gvim1 0.090 0.090 0.53% 5/6 [ 0] xlib gvim1 9.474 9.474 0.00% 4/6 The previous one was a bit wrong, I removed the cairo package from Arch [testing] and installed cairo from AUR (cairo-xcb) to see if that comes wiht the perf-trace utility. The previous output was generating using the trace from the [testing] cairo but with cairo-xcb (aur) installed. The one above was done with a new trace that I ran for the cairo-xcb.
I hear on the grapevine that a fix is now pending for the nVidia driver. Thanks for the bug report, and do let us know if the next driver update doesn't perform well.
Hi Patrick, Chris is quite right, and I thank him for bringing this to my attention; I fixed this on the driver side. On my system, this makes your trace go from 5.674 seconds per run to 0.297 seconds. This'll be delivered in an upcoming driver release; sorry for the inconvenience! Thanks, - Pierre-Loup
Hi, no problem at all. I will check the performance after the next updates(s) and keep an eye on the release notes. Thank you both for looking into this, Patrick
No change with the 295.40 driver.
Hi Patrick, Andrey, The newly-released 302.07 driver should fix this issue, in addition to other general goodness: http://www.nvidia.com/object/linux-display-ia32-302.07-driver.html http://www.nvidia.com/object/linux-display-amd64-302.07-driver.html Thanks for your patience; very sorry for the initial inconvenience.
Thanks for the update (both news and the driverwise). I will test right away when it hits the Arch repositories :)
Tab switching in Chromium didn't seem do improve with 302.07: http://code.google.com/p/chromium/issues/detail?id=121624 $ cairo-perf-trace chromium.18279 [ # ] backend test min(s) median(s) stddev. count [ 0] xcb chromium 1.973 1.987 0.62% 6/6 [ 0] xlib chromium 3.840 3.870 0.35% 6/6 [ # ] image: pixman 0.24.4 [ 0] image chromium 0.073 0.075 1.37% 6/6 [ # ] image16: pixman 0.24.4 [ 0] image16 chromium 0.089 0.090 0.51% 6/6
... sure. I think you need to file a different bug, and make sure you attach the trace so that people can reproduce the issue on their end.
Too bad it is not fixed in 295.53, only in beta.
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.