FFI Issues (was Re: [GOODIE] SDL + Cairo + Morph)

[Todd Fleming]

Brian Rice wrote:

> Is it inevitable that cairo_set_source_surface will be needed? If so,  
> what kind of problem is it to analyze its usage?

It and similar functions allow a bitmap to be a source for stroking and 
filling.  It's a pain to track because the source image can be switched 
in and out by save, restore, and other functions.  I'm probably going to 
have to make a stack to track the current source surface that mirrors 
Cairo's stack.  Unfortunately we'll need  to do this no matter what 
memory scheme we use if we want to expose Cairo's full feature set.

>
> In general, it might be wise to have all MemoryArea (temporary term  
> unless a better one occurs to someone) resources associated with an  
> SDL connection be formally related so that a master-level notion of  
> freeing all of them can be realized. Or, we can do as suggested in  
> the BUGS file, to add a counting semaphore to this resource type. The  
> trick is that image bitmaps could be re-used in the distant future  
> when closing one connection and opening another for the same window/ 
> contents is beneficial. But we could also regenerate them sometimes.
>
I assume you meant Cairo connection; the two are separate.  I only 
exposed 1 SDL resource, which I called "Window".

> There's also the optimization of not free()-ing a MemoryArea when  
> it's unused, to attach it to a pool that can re-use them when they  
> are of sufficient size and thereby avoid some malloc() calls.
>
High-performance malloc libraries do something like this.  You are 
linking to a high-performance malloc library, aren't you? ;)

Todd