[cairo] Why cairo 1.8.2 isn't out yet... :-(
Ginn.Chen at Sun.COM
Thu Oct 30 06:41:47 PDT 2008
The bug doesn't exist, if render is enabled or unavailable.
It only happens if render is disabled for some surface.
In xlib-expose-event.c, it does
On Oct 30, 2008, at 3:16 PM, Carl Worth wrote:
> 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
> 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-
> 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
> 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
> 1.6.4 to master that I may have made permanent my attempt to
> remove that locking. So Chris should double-check that for me.
> Meanwhile, I believe the original bugs we had that xlib-expose-event
> testing for led to crashes in that test. Today, however,
> xlib-expose-event isn't crashing but also isn't passing. I did a
> session which pointed to commit
> which adds a new _cairo_xlib_surface_solid_fill_rectangles function
> 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,
> 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
> So, Chris, is there a quick fix for xlib-expose-event that won't
> the performance advantage of
> If so, let's get it in and call 1.8.2 done already!
> [*] Tracking it down was a bit tricky since xlib-expose-event is a
> of one-off test that does a manual image comparison rather than
> cairo_test_run. As a result it doesn't generate a log file in the
> that our reports expect, so the final report doesn't say what test
> I think all we need to do here is to fix it so that anything that
> 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"
> 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
> to make little side branches and only do the temporary changes on that
> Another approach which I just used recently and am quite please with
> 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
> #if CAIRO_VERSION >= CAIRO_VERSION_ENCODE(1, 9, 0)
> which means that as soon as we increment the version from 1.8.x to
> or higher this code will automatically come back on. So I'm failsafe
> against my own forgetfulness in this case. Much better!
> cairo mailing list
> cairo at cairographics.org
Software Engineer, Browser Team
Sun Microsystems, Inc.
Phone: x82869 / +86-10-62673869
More information about the cairo