Bug 48395

Summary: [nvidia-295] Slow bitmap font rendering with cairo-1.12.0
Product: cairo Reporter: Patrick <freetheebee>
Component: generalAssignee: Carl Worth <cworth>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: emrecio, flo, pgriffais, wrar
Version: 1.12.0   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: My Xorg log.
strace output

Description Patrick 2012-04-06 12:36:53 UTC
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.
Comment 1 Chris Wilson 2012-04-06 13:26:57 UTC
This is a driver bug; please attach your Xorg.log.
Comment 2 Patrick 2012-04-07 04:23:24 UTC
Hi, I will add it on Tuesday. At the moment I don't have access to my pc.
Comment 3 Patrick 2012-04-10 03:40:57 UTC
Created attachment 59715 [details]
My Xorg log.
Comment 4 Chris Wilson 2012-04-10 03:52:09 UTC
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
Comment 5 Patrick 2012-04-10 09:29:56 UTC
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.
Comment 6 Chris Wilson 2012-04-10 09:59:14 UTC
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.
Comment 7 Patrick 2012-04-10 11:42:04 UTC
[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.
Comment 8 Chris Wilson 2012-04-10 11:49:28 UTC
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!
Comment 9 Patrick 2012-04-10 11:54:39 UTC
[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.
Comment 10 Chris Wilson 2012-04-10 15:21:25 UTC
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.
Comment 11 Pierre-Loup A. Griffais 2012-04-10 15:28:23 UTC
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
Comment 12 Patrick 2012-04-11 00:08:26 UTC
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
Comment 13 Andrey Rahmatullin 2012-04-14 00:46:31 UTC
No change with the 295.40 driver.
Comment 14 Pierre-Loup A. Griffais 2012-05-02 05:31:49 UTC
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.
Comment 15 Patrick 2012-05-02 13:27:59 UTC
Thanks for the update (both news and the driverwise).
I will test right away when it hits the Arch repositories :)
Comment 16 Jindrich Makovicka 2012-05-04 10:42:29 UTC
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
Comment 17 Pierre-Loup A. Griffais 2012-05-04 10:55:25 UTC
... 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.
Comment 18 Andrey Rahmatullin 2012-05-24 23:30:46 UTC
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.