[GOODIE] SDL + Cairo + Morph

Todd Fleming todd at flemingcnc.com
Sat Dec 10 14:24:16 PST 2005


Brian Rice wrote:

> This is very cool. The source structure looks good; I've applied it  
> in my local repository and will push it out to the server soon.

Thanks.

> I notice that you're concerned about the lack of locking by the GC.  
> The current GC does provide "pinning" to keep objects from being  
> moved around, but it's not sufficiently exposed and may not be  
> suitable for the kind of callback-like functionality you'd need.  
> There IS a way around this that I've been considering: basically by  
> using mmap() results as an ExternalResource which act like a File.  
> Like File's recent change, it'll support at:/at:put: as a ByteArray.  
> I do have some local files as scratch surface for this code, with a  
> plugin and an attempt to integrate with the VM-internal file support.  
> What do you think of that possibility?

PSObjectHeap_garbageCollect() clears the current pins.  It looks like 
the only cards that get pinned are ones that have objects that are 
referenced by the C stack.  The bitmaps most likely will not be 
referenced by the C stack when garbage collection occurs.  rootStack 
also doesn't work because it's a stack and has a fixed size. Imagine 
this: pass bitmap A to Cairo. pass bitmap B to Cairo. release bitmap A 
from Cairo.

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.

Here's another memory-related problem: is there a way to create 
destructors that get called when an object is garbage collected?  Right 
now Context will leak memory from the C heap if it gets garbage 
collected without the user sending the destroy message.

> Also, the relative complexity of the build process means that it's  
> probably time for us to look at better packaging support. Nick was  
> also looking at the possibility of statically linking our DLL's, but  
> this is just a speculative idea that we don't have answers for yet on  
> how well it would work. It would, however, make the PATH  
> modifications unnecessary.

Todd




More information about the Slate mailing list