[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