Hi Holger,
> On Mar 24, 2018, at 10:03 AM, Holger Freyther <[email protected]> wrote: > > > >> On 24. Mar 2018, at 16:42, Holger Freyther <[email protected]> wrote: >> >> >> >> 1.) FT2Handle class>>#startUp: isn't called. Which means >> FreeTypeFace>>#beNull has not been called yet! >> > > > >> I think implementing: >> >> FreeTypeExternalMemory class >> #bytes: aByteArray >> ^(aByteArray copy) >> pin; >> yourself >> >> could solve most of it? (We can argue about the copy...) > > It doesn't because most of FT2Plugin expects the "handle" it invented. But if > we look at it... > > FreeTypeFace>validate > SmalltalkImage>session > SessionManager class>default > SessionManager>currentSession > SmalltalkImage>session > FreeTypeFace>create > FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: > FreeTypeExternalMemory>validate > FreeTypeExternalMemory(FT2Handle)>isValid > > FreeTypeFace>>#validate already does: > > (session == Smalltalk session > ... > > > And this is why FreeTypeFace>>#create is being called and that will call > validate on the FreeTypeExternalMemory instance... > > > FreeTypeExternalMemory>validate just checks if the handle isValid but > remember 1st from my previous mail. We have not _yet_ cleared the FT2Handle > SubInstances.. So the memory is all good. > > > So back to the ideas. > > a.) Make sure FT2Handler class>>#startUp runs a lot earlier > b.) Find out which UI thing uses freetype earlier (but FreeType can be used > in non GUI apps. E.g. to draw text to an image...) > c.) Keep the session in FreeTypeExternalMemory as well and use it in > >>#validate.. (not relying on the startUp order) > d.) Re-write FreeType with Alien and just use the Plugin to conveniently > link/load to freetype.. I wonder if there is sense in trying to come up with a general memory handle object that includes a session identifier, so that attempts to free stake memory always fail. > holger
