[cairo] Detecting cairo_save/cairo_restore mismatchs

Behdad Esfahbod behdad at behdad.org
Sat Jul 21 11:25:54 PDT 2007


On Sat, 2007-07-21 at 05:32 -0400, Kalle Vahlman wrote:
> Hi!
> 
> I had a "bang your head against wall for a week and then find a silly
> mistake obfuscated by deepish rendering path"-kind of unpleasant
> experience with the state saving functions just now, and began to
> think that there should be something to check for this.

Hi,

I had the same but a couple days ago!  In the presentation program Carl
and I wrote for our presentation
( http://mces.blogspot.com/2007/07/guadec.html ), a cairo_restore() was
missing in one of the slides and causing misrendering of the following
slides when generating PDF output (but not with the Gtk+ viewer as it
recreated cairo_t's).

> So, after quick peek&hack at the sources, I made the attached patch to
> catch mismatched use of save/restore. The code simply keeps a balance
> of the calls and asserts if it's non-zero when the context is
> destroyed. This should make debugging such errors easier.
> 
> Note, I'm not proposing the patch for inclusion. The docs say that it
> is valid to leave the saved status stack unrestored (which is
> sensible), the patch does not allow this.

As you note this is not desirable.

What may be a solution is to have a new pair of save/restore functions
that do the right thing.  Ignoring the naming, you write:

  cairo_mark_t mark = cairo_mark (cr);

  ...draw...

  cairo_unmark (cr, mark);

The cairo_unmark() will pop to the point before the respective
cairo_mark().  Moreover, a cairo_restore() trying to pop a state saved
using cairo_mark() is an error.


> I guess this would be implementable within the cairo trace utility though?

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759





More information about the cairo mailing list