With latest trunk, when running firefox with X at 16 bpp, the rendering of most pages is heavily corrupted (see attachment). We reproduced it on different hardware and also with acceleration disabled so it doesn't look like an X driver issue. Here is my mozconfig: . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt-static ac_add_options --enable-optimize ac_add_options --disable-debug ac_add_options --enable-static ac_add_options --disable-shared ac_add_options --disable-libxul ac_add_options --disable-tests I get the same results when I use the system cairo.

I forgot to mention that this was working fine with 1.9a pre6.

What do you see when you enter the following url in the location bar? data:text/html,<div%20style="background:url('chrome://browser/skin/tabbrowser/tabbrowser-tabs-bkgnd.png');height:30px"/> It should display a grey bar with a gradient. If you see nothing then this is likely the second issue in bug 390787. Interesting you get this with system cairo, as bug 390787 seemed to show up when the mozilla tree cairo changed from 1.4.2 to 1.5.1. What version is you system cairo?

Yeah I see nothing with your testcase (and the one using the img element in bug 390787 works). My system cairo is 1.4.10.

Btw I think cairo 1.4.10 + xulrunner 1.9a6 works fine.

From bug 390787 comment 35 are some comments relevant to this but I'll summarize here: The url above renders blank, but the same image renders fine when in an img element (not a background): data:text/html,<img%20src="chrome://browser/skin/tabbrowser/tabbrowser-tabs-bkgnd.png"%20height="30px"%20width="300px"/> Setting a breakpoint in a debug build at _cairo_error shows CAIRO_STATUS_INVALID_FORMAT with this stack: https://bugzilla.mozilla.org/attachment.cgi?id=278260 which is this code: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/cairo/cairo/src/cairo-xlib-surface.c&rev=1.28&mark=659-662#645 The error probably propagates the error to the cairo_t (after being translated to CAIRO_STATUS_NO_MEMORY), meaning that no further rendering happens for that cairo_t. There has been some upstream work in cairo on unsupported formats that may be helpful.

Marco, do you happen to have a xulrunner 1.9a7 with system cairo you can test?

Output of "xdpyinfo -ext RENDER" for ktomlinson

The above xdpyinfo output was for a 24-bit depth but the red green blue masks still only cover 16-bits. Previously JD attached output with 16-bit depth here: https://bugzilla.mozilla.org/attachment.cgi?id=279334 JD is using an nvidia display driver. I tried a 16-bit DefaultDepth Xserver but couldn't reproduce with a vesa driver. JD's xdpyinfo reports 8 "significant bits in color specification", but, with my vesa driver, 6 bits was reported (which seems more reasonable to me). Marco and Andrew: Are you able to attach similar "xdpyinfo -ext RENDER" output, please?

I see the same problem using X.org's intel driver, I'm attaching the "xdpyinfo -ext RENDER" output. I'm running Debian unstable with cairo being 1.4.10-1.

Thanks, m. That's pretty similar to what I'm seeing, including 6 significant bits, so Marco and Andrew, no need to attach further output. I'd be interested to hear if anyone sees this bug with 24-bit color though.

Hmm.. interesting.. With 24-bit depth I no longer see the problem.

a7 doesn't build with system cairo. (with internal cairo it works fine).

I'm somewhat fixed...Apparently the setting of my X dept to 24-bit didn't take effect till i rebooted...Now the latest hourly of FF3 is working fine.

does this still happen with the latest nightlies at 16bpp?

I don't see it any more (16bpp). I switched to 24bpp a month ago or so, so I wouldn't know - when/how was it fixed?

Seem to be fixed here too.