[cairo] build now works

[Chris Wilson]

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! :)
Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre