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

[Todd Fleming]

Brian Rice wrote:

> Okay, I read into your cairo_patch and it makes more sense to me. But  
> I need to know: when Cairo releases a bitmap, does it just call free 
> () itself, or is there some way that you know that it's done with the  
> memory area? If it tries to own the memory area, then we'll probably  
> just have to make a memory pool manager in the C-side plugin - even  
> with fixed-offset memory allocations, Slate and Cairo can't afford to  
> fight over the ownership of memory areas.

Cairo does not free() a bitmap that was given to it by 
cairo_image_surface_create_for_data().  Cairo only tries to access that 
memory when it uses a surface that references it.  Thus cairo.slate has 
to track which surfaces reference which bitmaps and which contexts 
reference which surfaces.  I'm holding back on functions that will make 
this difficult to track (eg. cairo_set_source_surface).

>
>> mmap() sounds like a better workaround than what I currently do,  but 
>> only if the mmap files work like a heap.  i.e. several hundred  
>> in-memory bitmaps should not translate to several hundred mmaped  files.
>
>
> Well, that's why mmap() can be called in various ways:
> http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html
>
> About protocol, by default they are going to look like ByteArrays, or  
> at least that's the easiest Slate API to provide. Making it look  
> transparently like a heap would be extremely tricky.
>
> I was going to make an argument about using mmap() in a way that the  
> file is never touched or sync'd, or to try the typed memory object  
> approach, but it occurred to me that this may not be that portable  
> (the spec says as much). What may really be needed is something as  
> simple as an ExternalResource for malloc() results, which would  
> obviously need finalizers but would get us our functionality without  
> as many portability problems.
>
> What we're talking about here could make our FFI interface much  
> different, so we should put some thought into the implications either  
> before or after implementing it.

It would be nice if whatever approach we take, that memory can get 
stored as part of the image.  Bitmap data shouldn't be lost just because 
Cairo touched it.

Todd