Bug 4187 - Graphics corruption on VirtualBox
: Graphics corruption on VirtualBox
Status: VERIFIED FIXED
Product: opensolaris
desktop
: unspecified
: VirtualBox/amd64 OpenSolaris
: P1 critical (vote)
: in-200811
Assigned To: Erwann Chénedé
: Watcher account for desktop bugs
:
:
:
:
: 2413
  Show dependency treegraph
 
Reported: 2008-10-23 09:42 UTC by Glynn Foster
Modified: 2008-10-29 22:53 UTC (History)
6 users (show)

See Also:


Attachments
Screenshot of panel graphics corruption (324.67 KB, image/png)
2008-10-25 02:45 UTC, Glynn Foster
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Glynn Foster 2008-10-23 09:42:59 UTC
Looks like in an alpha build 100, there's a graphics corruption bug, affecting
the panel
Comment 1 Glynn Foster 2008-10-23 15:03:01 UTC
Looks like this is specific to the panel - and related to transparency/setting
the panel background to the transparent image. Specific only to VirtualBox.
Updating to build 101 to see if this magically fixes the bug.
Comment 2 Glynn Foster 2008-10-23 15:14:38 UTC
Re-produced with build 101 from the dtpkg.ireland:9100 - Erwann, over to you.
Comment 3 Erwann Chénedé 2008-10-24 01:19:52 UTC
I'm installing b101 on virtualBox atm.
I can't reproduce it on b100.
Can you please attach screenshot ?
Comment 4 Glynn Foster 2008-10-24 04:37:52 UTC
Looks like the graphics corruption goes while installing the guest additions.
Will attach a screenshot of the previous issues though.
Comment 5 Glynn Foster 2008-10-25 02:45:44 UTC
Created an attachment (id=648) [details]
Screenshot of panel graphics corruption
Comment 6 David Comay 2008-10-26 21:13:15 UTC
I'm seeing this as well with my build 101 repository (which includes some build
100 branded packages).
Comment 7 Ginn Chen 2008-10-27 20:49:53 UTC
*** Bug 4208 has been marked as a duplicate of this bug. ***
Comment 8 Erwann Chénedé 2008-10-28 08:13:37 UTC
From Ginn's investigation :

-=-=-

The problem is certain XOrg + certain driver / video adapter will fail on some
XRenderComposite() calls.
If it fails, the result could be invisible or corruption.

I think snv_100 changed something in XOrg drivers, so we see #4187.

libcairo detects XOrg vendor string and release version for the buggy render.
We use "Sun Microsystems, Inc." for vendor string, so libcairo doesn't know
whether we have a buggy render or not.

See the code below:
285 display->buggy_repeat = FALSE;
286 if (strstr (ServerVendor (dpy), "X.Org") != NULL) {
287 /* When modularized, the X.Org server VendorRelease was
288 * bogusly reset to a very small number, without any change in
289 * the ServerVendor string. We avoid considering the new
290 * servers with the small number as buggy by restricting the
291 * test to known bad releases. But there could be a problem
292 * again in the future if X.Org server versions ever climb
293 * back up to 6.7 or 6.8. */
294 if (VendorRelease (dpy) >= 60700000 && VendorRelease (dpy) <= 60802000)
295 display->buggy_repeat = TRUE;
296
297 /* But even the new modular server has bugs, (bad enough to
298 * crash the X server), that it so happens we can avoid with
299 * the exact same buggy_repeat workaround. We've verified that
300 * this bug exists as least as late as version 1.3.0.0, (which
301 * is in Fedora 8), and is gone again in version 1.4.99.901
302 * (from a Fedora 9 Beta). Versions between those are still
303 * unknown, but until we learn more, we'll assume that any 1.3
304 * version is buggy. */
305 if (VendorRelease (dpy) < 10400000)
306 display->buggy_repeat = TRUE;
307 } else if (strstr (ServerVendor (dpy), "XFree86") != NULL) {
308 if (VendorRelease (dpy) <= 40500000)
309 display->buggy_repeat = TRUE;
310 }

For cairo 1.6.x, by default, buggy_repeat is TRUE. That's why Firefox 3 before
snv_101 has no problem with www.opensolaris.com.
For cairo 1.7.x, by default, buggy_repeat is FLASE.

For OS200811, I think the fix could be, 
#1, always set display->buggy_repeat to TRUE if Vendor is Sun

#2, set display->buggy_repeat to TRUE if Vendor is Sun and Release < 10400000
(The risk is we don't know whether the root cause is gone for 10400000 in VBox)


I have tested #1, both #4187 and #4208 are gone.

The performance might be slightly down by setting buggy_repeat to TRUE.


=-=-=-

The solution is to reset buggy_repeat to TRUE in 1.7.4

See patch below :

diff -rup ../amd64/cairo-1.7.4/src/cairo-xlib-display.c
cairo-1.7.4/src/cairo-xlib-display.
c
--- ../amd64/cairo-1.7.4/src/cairo-xlib-display.c    2008-06-22
20:40:27.000000000 +0200
+++ cairo-1.7.4/src/cairo-xlib-display.c    2008-10-28 15:03:17.590515767 +0100
@@ -64,6 +64,8 @@ struct _cairo_xlib_job {

 static cairo_xlib_display_t *_cairo_xlib_display_list;

+static int buggy_repeat_force = -1;
+
 static void
 _cairo_xlib_call_close_display_hooks (cairo_xlib_display_t *display)
 {
@@ -316,6 +318,17 @@ _cairo_xlib_display_get (Display *dpy)
     if (VendorRelease (dpy) <= 40500000)
         display->buggy_repeat = TRUE;
     }
+    /* workaround; see http://defect.opensolaris.org/bz/show_bug.cgi?id=4187
*/
+    if (buggy_repeat_force == -1) {
+        if (getenv("CAIRO_NO_BUGGY_REPEAT"))
+            buggy_repeat_force = 0;
+        else
+            buggy_repeat_force = 1;
+    }
+
+    if (buggy_repeat_force)
+        display->buggy_repeat = TRUE;
+

     display->next = _cairo_xlib_display_list;
     _cairo_xlib_display_list = display;
Comment 9 Erwann Chénedé 2008-10-28 09:49:36 UTC
the fix will be available in b101a
Comment 10 Glynn Foster 2008-11-03 18:09:58 UTC
*** Bug 4469 has been marked as a duplicate of this bug. ***