[cairo] GL backend work

[Zach Laine]

On Tue, Jan 12, 2010 at 4:13 PM, Eric Anholt <eric at anholt.net> wrote:
> On Tue, 12 Jan 2010 11:56:28 -0600, Zach Laine <whatwasthataddress at gmail.com> wrote:
>> On Tue, Jan 12, 2010 at 6:09 PM, Eric Anholt <eric at anholt.net> wrote:
>> > Note that texture border colors are a bit tricky.  Most hardware will
>> > sample texture border color's alpha as 1 when the texture format itself
>> > doesn't have an alpha channel.  This is not what's desired for our
>> > common usage of GL_CLAMP_TO_BORDER ("please sample 0 alpha outside of
>> > the texture").  In order to do this right, I think we're going to want
>> > to promote CAIRO_CONTENT_COLOR to be RGBA and adjust our rendering to
>> > fill the alpha with 1.
>>
>> Do you mean that you'd like to make all cairo_gl_surface_t's use RGBA?
>>  If so, I guess that would fix things too.  It just seems to me that
>> if the user explicitly asks for RGB, she should get it.  Silently
>> padding out the format to make this case work seems wrong to me.  It
>> seems that the user should instead just be notified that she needs to
>> use RGBA to get proper alpha blending.
>
> We have a similar experience inside of the OpenGL drivers.  The user
> asks for the behavior of RGB, and we have to provide the behavior, but
> if the hardware doesn't actually support RGB with the semantics we
> require, then we have to do RGBA and work around it ourselves.  In the
> Intel case, we can't do blending to XRGB destinations, so we always
> treat them as ARGB and tweak the blender to get XRGB behavior.  The
> workarounds aren't all that painful, so we don't necessarily have to go
> hunt down hardware guys and yell at them (though we might ask kindly for
> our lives to be easier).

Ok.

> Oh, there's no padding going on here, if that was the concern with
> moving to ARGB.  Graphics hardware doesn't do 24bpp RGB, it does
> 32bpp/24 depth xRGB.  So we're not going to be wasting any more memory.

Is that always true, though?  Certainly not for software
implementations, and are you sure there are no embedded systems that
do otherwise?  More importantly, though, is that RGB and RGBA behave
subtly differently in certain cases, and so if as a user I ask for an
RGB texture, but get an RGBA texture, that's not necessarily going to
work for me.

After looking at this a bit more, it looks like making the
intermediate texture RGBA doesn't actually fix things after all.
However, in _cairo_gl_set_src_operand(), there's this bit of code:

	/* Wire the src alpha to 1 if the surface doesn't have it.
	 * We may have a teximage with alpha bits even though we didn't ask
	 * for it and we don't pay attention to setting alpha to 1 in a dest
	 * that has inadvertent alpha.
	 */
	if (setup->src.operand.texture.has_alpha)
	    glTexEnvi (GL_TEXTURE_ENV, GL_SRC0_ALPHA, GL_TEXTURE0);
	else
	    glTexEnvi (GL_TEXTURE_ENV, GL_SRC0_ALPHA, GL_CONSTANT);

Making the intermediate texture RGBA and changing the code above
always to use GL_TEXTURE0 instead of GL_CONSTANT does fix things.  You
have to do both.  Here's where it gets interesting, though.  Always
using GL_TEXTURE0 fixes these tests:

xcomposite-projection
surface-pattern-scale-up
rotate-image-surface-paint
filter-nearest-offset
device-offset-fractional
clip-unbounded (argb32 only)

However, it also causes these new failures:

unbounded-operator (rgb24 only)
surface-pattern-operator (rgb24 only)
rgb24-ignore-alpha (argb32 only)
push-group-color (argb32 only)
operator-alpha (rgb24 only)
operator (rgb24 only)
mime-data (argb32 only)
filter-nearest-offset
clip-operator (rgb24 only)

So, it looks like we have a one-size-fits-all approach, and it turns
out that size is not so universal.  I haven't yet looked into the
exact cause of this yet, but I though Eric or someone might have some
insight as to why the comment and the conditional are there.  Anyone
know offhand of a better predicate than the one the conditional above
uses?

>> I actually have no idea what cairo-traces is.  Could you explain this briefly?
>
> Oh, they're awesome.
>
> cd ~/src/cairo/perf
> git clone git://anongit.freedesktop.org/git/cairo-traces
> (cd cairo-traces && make)
> CAIRO_TEST_TARGET=gl ./cairo-perf-trace -i 3 ~/src/cairo/perf/cairo-traces/benchmark/firefox-talos-gfx.trace

This doesn't work for me.  The make step fails like this:

cc  -D_REENTRANT -I/usr/local/include/pixman-1
-I/usr/local/include/freetype2 -I/usr/local/include
-I/usr/include/cairo -I/usr/include/directfb -I/usr/include/libpng12
csi-bind.c -lcairo   -lcairo-script-interpreter -o csi-bind
csi-bind.c:2:38: error: cairo-script-interpreter.h: No such file or directory
make: *** [csi-bind] Error 1

cairo-script-interpreter.h exists, and the cairo-script-interpreter
lib is built, but it looks like cairo-traces can't find it.  What am I
doing wrong?

Zach