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

[Ginn Chen]

Interesting.
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  
cairo_boilerplace_xlib_surface_disable_render (surface);

Ginn

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  
> 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!
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo

--------
Ginn Chen
Software Engineer, Browser Team
Sun Microsystems, Inc.
Phone: x82869 / +86-10-62673869
Fax: +86-10-62780969