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

[Brian Rice]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Dec 10, 2005, at 9:07 PM, Todd Fleming wrote:
> 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().

Okay, not having asynchronous free() calls is a big invariant to  
have, safety-wise.

> 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).

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

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.

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.

>>> 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.

Of course I agree. What can make this happen is the use of the new  
Image saveActions hook, to copy the data into a temporary storage...  
I imagine that an extra slot for a MemoryArea ExternalResource type  
would not be asking too much so that the binary data (a ByteArray)  
had a "place to go" after a free() or on an Image save. Startup  
actions can then restore it.

Another MemoryArea design note: the "locator" would just be the size  
of the area needed, since the locator idea is a specification of the  
resource's creation. I'd use a separate attribute concept to get the  
addresses and offsets of data, although if I can, I'll try to shuttle  
that information around below the image level.

I'll try to code this up tomorrow. This should not have some of the  
complications that the mmap() attempt has had.

- --
- -Brian
http://tunes.org/~water/brice.vcf

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDm+00PVkAvLW1zf4RAhb0AJ0f24vWImusw4aIJ2r3HBoKtRwvcwCff6ZJ
k31Qb+weGysgWFUc7n+yZps=
=Gajf
-----END PGP SIGNATURE-----