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

[Brian Rice]

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


On Dec 12, 2005, at 6:11 PM, Todd Fleming wrote:

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

Okay; I guess we'll learn what patterns work as we go, and hopefully  
encapsulate them. If it helps, the MemoryArea API supports sessionDo:  
just like any other ExternalResource.

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

Eh, I was talking about future ideas, not what you're doing. It  
doesn't matter right now; this is just me trying to outline what we  
might need later.

>> 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? ;)

Never. :) I'd rather let the user do this and generalize it in the  
image. We can optimize the operation of the manager later.

But, for reference, what are some high-performance malloc libraries  
worth learning from?

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

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

iD8DBQFDnjVLPVkAvLW1zf4RAhEUAKCxPjYWfZujoJq+Nuzb2yhI2XYOWgCcCnUj
0W9ML4TGriU80Kc/9+tsoGY=
=bk0j
-----END PGP SIGNATURE-----