[cairo] Why cairo 1.8.2 isn't out yet... :-(

[Carl Worth]

I really wanted to finish this tonight, (I even pushed out a commit to
NEWS that has 2008-10-29 as the date of 1.8.2), but alas when doing the
final "make release-publish" I got:

	1 of 205 tests failed

which was surprising to me, because I was sure I had recently gotten 0
test failures.

I tracked this down to xlib-expose-event[*]. Looking into the history
here, things are pretty messy:

The xlib-expose-event test was added after we accidentally re-introduced
a nasty bug into 1.6.2 that we had previously fixed. For 1.6.4, to fix
that bug I "temporarily"[**] reverted the commit that added some
locking, (while also introducing the bug). This revert is commit
8f1c8d4b26d6da11101c51ef388d1dcc7177cfb4.

In parallel to that, Chris added the xlib-expose-event test and also a
fix for it. One concern I had is that when I merged in the changes from
1.6.4 to master that I may have made permanent my attempt to temporarily
remove that locking. So Chris should double-check that for me.

Meanwhile, I believe the original bugs we had that xlib-expose-event was
testing for led to crashes in that test. Today, however,
xlib-expose-event isn't crashing but also isn't passing. I did a bisect
session which pointed to commit 07fef4f4802639a2cb16284841635d1bcc9b8e8f
which adds a new _cairo_xlib_surface_solid_fill_rectangles function for
non-Xrender servers.

As it looks in that commit, that function is really wrong, (not using
_cairo_xlib_surface_ensure_gc to get a GC for example), but in current
master it's quite a bit cleaner, (and also quite different in how it
actually renders). I checked and with master I was able to make
xlib-expose-event pass by simply bypassing this function, (that is, just
returning UNSUPPORTED from _cairo_xlib_surface_fill_rectangles rather
than calling it.

But that seems an especially unkind thing to do performance-wise for
people running cairo on Xrender-less systems.

For reference, I checked and xlib-expose-event also fails on 1.8.0. I
missed that because I did the release then with xlib testing disabled.
I've repented of that now, and am now using Xvfb to get good testing
results from the xlib backend, (without the dozen or so supposed
failures due to driver issues if I just run against my own X server).
And I did document in test/README and RELEASING this approach of using
Xvfb.

So, Chris, is there a quick fix for xlib-expose-event that won't destroy
the performance advantage of _cairo_xlib_surface_solid_fill_rectangles?
If so, let's get it in and call 1.8.2 done already!

Thanks,

-Carl

[*] Tracking it down was a bit tricky since xlib-expose-event is a sort
of one-off test that does a manual image comparison rather than calling
cairo_test_run. As a result it doesn't generate a log file in the format
that our reports expect, so the final report doesn't say what test
failed.

I think all we need to do here is to fix it so that anything that calls
cairo_test_init and cairo_test_fini will generate a proper log file.
That might require augmenting cairo_test_fini to accept the test's
return value, but that should be simple enough.

[**] It seems I regularly find myself doing some "temporary" changes
just before a release, (planning to set things back "right" immediately
after the release). And every time I do this I terrify myself that I'm
going to forget to undo the temporary change. And I've probably done
exactly that several times. I suppose one option to avoid that would be
to make little side branches and only do the temporary changes on that
branch.

Another approach which I just used recently and am quite please with is
the way I temporarily disabled the testing of the svg12 target for the
1.8.2 release. Instead of throwing in an #if 0 to disable the code, I
used:

	#if CAIRO_VERSION >= CAIRO_VERSION_ENCODE(1, 9, 0)
	...
	#endif

which means that as soon as we increment the version from 1.8.x to 1.9.0
or higher this code will automatically come back on. So I'm failsafe
against my own forgetfulness in this case. Much better!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20081030/7896e06b/attachment-0001.pgp