Buttons rendered wrong (with white background) with nvidia-current

Bug #605979 reported by Maia Everett on 2010-07-15
This bug affects 11 people
Affects Status Importance Assigned to Milestone
cairo (Ubuntu)
gtk2-engines-murrine (Ubuntu)
nvidia-graphics-drivers (Ubuntu)

Bug Description

Binary package hint: gtk2-engines-murrine

With cairo 1.9 and the NVIDIA proprietary driver, buttons fail to render properly with the Ambiance and Radiance themes, among others. See attached screenshot (Finery theme).

Maia Everett (linneris) wrote :
Maia Everett (linneris) wrote :


gtk2-engines-murrine (0.90.3+git20100323-0ubuntu4) maverick; urgency=low

  * Add debian/patches/10_white_widgets.patch:
    - Fix incorrect rendering of button background with cairo 1.9. (LP: #605979)

 -- Maia Kozheva <email address hidden> Fri, 16 Jul 2010 00:56:25 +0700

Changed in gtk2-engines-murrine (Ubuntu):
status: New → Confirmed
Maia Everett (linneris) wrote :

Updated debdiff, also fixes progressbars and white borders on pressed buttons.

Maia Everett (linneris) wrote :

Updated debdiff, fixing problems with rendering backgrounds in RGBA mode.

Maia Everett (linneris) wrote :

Fixed rendering of separators. From what I can tell, the only widgets that display incorrect whiteness now are custom message list column headers in Evolution. I haven't found the reason yet, though.

Fabien Tassin (fta) wrote :

Excellent. Just tested it and it fixes http://code.google.com/p/chromium/issues/detail?id=48869
(and much more)

Sebastien Bacher (seb128) wrote :

Thank you for your work on this issue

Changed in gtk2-engines-murrine (Ubuntu):
importance: Undecided → Low
Sebastien Bacher (seb128) wrote :

Could you explain what issue your change solve and send to the upstream bugtracker?

Maia Everett (linneris) wrote :

Murrine upstream is wary about this patch, because cairo_clip is slow and this bug only occurs with the NVIDIA drivers.

Any ideas what could cause such a rendering bug to be dependent on the graphics driver? Could it be cairo-xlib versus cairo-gl, and is cairo-gl even used in Maverick's GTK? If it is, is there any way to force GTK/Cairo to use a specific backend with a different driver to test this?

Andrea Cimitan (cimi) wrote :

Gtk+ is not using (and will not) cairo-gl. Cairo won't use GL (it will be much slower using opengl).
Please test if the bug is in the graphic driver or not. I'm not against patching murrine if the bug is in murrine, but if the bug is in cairo and/or the graphics driver I don't know why I should add a workaround for their bug in another software.
Did you get my point? Ty

Changed in murrine:
status: Unknown → New

Benjamin Otte (Cairo dev) and I debugged this.

We found that setting the the "buggy_gradients" field to true on the (cairo private) cairo_xlib_display_t worked around the problem. So it seems likely it's a bug in how the nvidia drivers handle gradients.

Benjamin Otte (Company) (otte) wrote :

As I said in the linked GNOME bug:

It's a bug in the nvidia driver.

If anybody wanted to work around this problem (other than installing nouveau), I'd suggest looking in Cairo's _cairo_xlib_device_create() in src/cairo-xlib-display.c and ensure that display->buggy_gradients is set to TRUE. Setting it to TRUE unconditionally will cause slowdowns on all drivers, so detecting the nvidia binary driver sounds like a good idea. I've been told by the Xorg developers that checking for the availablility of the NV-CONTROL extension works for that.
I'm not sure I'd want that patch upstream as it isn't a reliable check, but as a Maverick-specifc Ubuntu patch, it certainly makes sense.

Sebastien Bacher (seb128) wrote :

Thanks Benjamin and Evan to debug this one

Maia Everett (linneris) on 2010-07-23
Changed in gtk2-engines-murrine (Ubuntu):
status: Confirmed → Invalid
Harry (harry33) wrote :

As far as this is a bug against cairo (libcairo2) this is a duplicate of the bug " #601220.

Harry (harry33) wrote :

Please read through the bug #601220
It is also worth mentioning that arch-linux with the new cairo and with NVidia graphics card and proprietary drivers do not show this color blend / gradient regression. This seems to be ubuntu-specific issue.

Harry (harry33) wrote :

You may also want to take a look at the bug #595845

Sebastien Bacher (seb128) wrote :

unsubscribing the sponsor, as stated in the bug the issue is a nvidia driver one, thank you for your work on that in any case! ;-)

Aaron Plattner (aplattner) wrote :

Hi Benjamin. This is the first I've heard of this bug, so I'll try to take a look at it as soon as I can.

Please note that just checking for the NV-CONTROL extension is not sufficient, because some screens may be using the NVIDIA driver while others use different drivers. If the extension exists, you can use XNVCTRLIsNvScreen to query if a given screen is using the NVIDIA driver. However, please don't do that. I'd much rather just fix the driver if it's broken then have a driver-specific workaround in place that we need to get rid of eventually.

Sebastien Bacher (seb128) wrote :

the workaround suggested has been applied to maverick for now since server side gradients seems to create sloweness on nouveau and ati in addition of the nvidia issues described there, it's only a workaround though and might be dropped again later so it would still nice to have the drivers fixed to work correctly

Changed in murrine:
importance: Unknown → Medium
tags: added: patch
Changed in murrine:
status: New → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.