FFI Issues (was Re: [GOODIE] SDL + Cairo + Morph)
Brian Rice
water at tunes.org
Mon Dec 12 18:43:22 PST 2005
-----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-----
More information about the Slate
mailing list