[cairo] build now works
chris at chris-wilson.co.uk
Sat Jun 18 05:27:26 PDT 2011
On Sat, 18 Jun 2011 08:08:34 -0400, James Cloos <cloos at jhcloos.com> wrote:
> >>>>> "US" == Uli Schlachter <psychon at znc.in> writes:
> First, after re-compiling cairo master with --disable-xlib-xcb
> (instead of --enable) everything works fine.
> >> ABORT: RenderChangePicture: BadValue (integer parameter out of range
> >> for operation); 2838 requests ago: file nsX11ErrorHandler.cpp, line
> >> 203
> US> This is weird. RenderChangePicture doesn't get an operator as an
> US> argument. I guess this means that the missing operator causes a
> US> fallback which avoids the "evil" code path.
> US> Could you tell us a little more about your setup? Which versions of
> US> things are you using? What exactly do you make gecko do to cause
> US> these problems?
> Everything FDO is master. All recompiled again this week on both the
> server and client boxen. That is when the RenderChangePicture errors
> and/or server lockups started. I've used --enable-xlib-xcb for quite
> a few months.
Can you grab a cairo-trace of an example where xlib-xcb fails? Does the
replay reproduce the failure. We can also work on cairo-test-trace to
work out and produce some test cases.
> The geckos are SM-2.1, FF-3.6, FF-4.0 and FF-5.0 betas. All compiled
> to use the system cairo.
> The X server is 32-bit x86; card is a Radeon Mobility M7 LW (r100 class).
> The client box is amd64. Everything is X over tcp, not ssh tunneling.
> (The two have a p-t-p ethernet, separate from the main lan.)
> US> Could you tell us the results of the following commands?
> US> $ xdpyinfo -ext RENDER | grep 'RENDER version'
> US> (This should be 0.11)
> It is.
> US> $ grep VERSION /usr/include/xcb/render.h
> US> (I'd expect 0.10 here, xcb-proto was only updated 5 days ago for render 0.11)
> 0 11 0
> Disabling cairo's xlib-xcb also fixed three other anomalies which the
> geckos triggered more than any other apps.
> The first was that, with SM-2.1 and FF-4.0 or later, elements of the UI
> whose css specified 'transparent' rather than 'transparent !important'
> rendered black-on-black instead of black on whatever was layered below.
> The transparency gets lost somewhere along the way.
> The second was that, as VRAM filled (the card only has 64M) some
> rectangles of text would scramble. The rects were one line tall
> and usually about 16 or so EMs wide. Call it about 25Ã400 px, Â±.
> Often the scramble was a chunk of text from somewhere else on the
> screen, but severely sheared.
> (Those last two bugs had been there for the last few months.)
These sound like driver issues, tbh.
But xlib-xcb is proving invaluable in finding issues! :)
Chris Wilson, Intel Open Source Technology Centre
More information about the cairo