[cairo] [PATCH] fix bugs 15797 (1.8) and 18632 (master)

[Chris Wilson]

On Wed, 2008-12-10 at 06:38 +0100, Paolo Bonzini wrote:
> > Also, I'm a little frightened that keeping an implicit reference around
> > will make it easy unintentionally reference a freed area of memory. It
> > may be better to just make a copy of it. Aside: If allocation/free overhead is
> > dominating, an object pool might be a better solution.

(The allocation of the pattern object itself is not the only issue, we
also have a heap allocation for the colour stops belonging to gradients
- even when make a stack copy.)

> Yes, I thought about it for a while before doing it this way, but then
> these functions appear just in a couple of possible call stacks.
> 
> One allocation might be okay because anyway the code is allocating
> Quartz objects on the heap, but then why does Cairo use stack-allocated
> objects in the first place?
> 
> Another possibility is to *always* copy the pattern to be
> stack-allocated in cairo-gstate.c, and assert here that the reference
> count is 0.

The reason why cairo-gstate.c does not do the stack-copy is that it
incurs significant overhead on renderbench versus plain XRender (and the
heap copy that snuck into 1.6 was even more painful for all work loads).
If you have any doubts over the lifetime, just make the copy and only
worry about if it ever appears on a profile.
-- 
Chris