[cairo] Proposal: cairo_save_state/cairo_restore_state

[Behdad Esfahbod]

On Tue, 24 Jan 2006, Alexander Larsson wrote:

> On Mon, 2006-01-23 at 23:49 -0500, Behdad Esfahbod wrote:
>
> > Before you get too much into implementation, can I request a
> > feature?  Make it copy-on-write?  All you need to do is to add a
> > flag to cairo_state_t stating if it's a saved state.  Then, any
> > function modifying a cairo_state_t will first check if it's a
> > saved state, if it is, it will duplicate it first and update the
> > cario_t.  It probably needs a bit of refactoring since you may
> > have not the cairo_t around when modifying cairo_state_t, but
> > this feature makes creating a cairo_t, configuring it (using
> > saved states) and using it extremely fast.  That was the
> > intention of the bug reporter at least...
>
> Copy on write is generally cool, but it can have threadsafeness issues.
> I.E. If you want it threadsafe you take a performance hit in the
> locking. If you don't make it threadsafe then the rules to use state
> objects in a multithreaded app gets really complicated, as its hard to
> know which objects are the same.

You are right generally, but in this case, since saved states are
immutable and cairo_t objects are not threadsafe anyway (cannot
be used from two threads at the same time), I don't think any
locking is needed, and the semantics I described does the job.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"