GNOME Bugzilla – Bug 79463
pixmap rendering errors when running remotely on os x
Last modified: 2011-02-04 16:10:03 UTC
see attached screenshot (a picture is worth a thousand words) client setup: XFree86 4.2 (XDarwin) on Mac OS X 10.1, current GTK 2 from CVS (gtk-2-0 branch) server setup: XFree86 4.2 on RHL "skipjack" beta 2, x86 owen mentioned it is probably in gdkdrawable-x11.c:convert_to_format() feel free to assign this to me if you aren't going to look at it... i'll probably look into it this week a bit.
Created attachment 7849 [details] screenshot showing the bug
Putting on 2.0.4, since the problem isn't tracked down yet.
this seems to have disappeared after i built gtk with shm disabled. (there were a lot of problems with it enabled) does this make sense? should this be closed?
Makes no sense to me at all that it could disappear with SHM disabled. GTK+ is clearly not succeeding in rendering with SHM on a remote display... I don't think we should close bugs unless either: - We have it tracked down to a problem in other software and have reported the problem upstream. - We have some sort of resolution on the problem Building GTK+ with --disable-shm should *never* be necessary and the fact that the option is there at all is basically a legacy of bugs in SHM handling in old versions of GTK+.
here are the comments which led me to disable shm in gtk: http://fink.sourceforge.net/faq/usage-general.php#gnome-icons there were all sorts of weird things when shm was enabled: * splash screen would draw things in the wrong place * gimp would display garbage when loading tiffs * nautilus thumbnailing would draw garbage * pixmaps would start disappearing from applications and the panel i don't see any of these after disabling shm. but, will leave this bug open since it wouldn't explain why stric also saw this.
i can reproduce this when running on sparc (solaris) and ppc (darwin) to x86 (linux) displays when the display is 16 bit. if i switch to 24 bit, it works fine.
federico, do you have a ppc/sparc in .mx? i'm getting pretty lost in that code...
If its' occurring between Solaris and XFree86, it isn't in convert_to_format(), which is RENDER specific code.
yeah it turns out my darwin gtk was being built w/o xft support for some unknown reason.
I just fixed this yesterday for the hp-ux dudes on 1.4. I'm integrating the patch right now.
OK, it is on gdk-pixbuf, gtk HEAD, 2-0, and multihead now.