[cairo] Proposal: cairo_save_state/cairo_restore_state
behdad at cs.toronto.edu
Tue Jan 24 05:09:20 PST 2006
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.
"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
More information about the cairo