Anyway, freetype is deceiptivly slow.
This is because it will invoke a primitive for each and every Character
glyph, rather than for string chunks.
We should do something...


2013/11/15 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>

> For FreeType, it was true: many nasty extensions and many nasty overrides
> made the load rather intrusive...
> Now, the package split is not at good boundary, the constants are not
> enough: indeed, during some initialization, the layout of most (all?)
> classes known to the primitives is scanned, thus all these classes must be
> present in the VM-Making image...
>
>
> 2013/11/15 tim Rowledge <tim at rowledge.org>
>
>>
>> (Various attributions probably screwed up by me using a soft keyboard.
>> Please don't be offended )
>> >>
>> >> Because otherwise "so what" if FFI includes the constants and VMMaker
>> >> depends on it solely for that portion of it?  How many methods making
>> >> up FFI are we talking about?  There are plenty of _other_ methods in
>> >> the image which are not being used by VMMaker, what about them?
>> >>
>> In some cases it won't matter but in others it may be rather important.
>> FFI is an example where I think it is important to be able have only the
>> constants parcel added to vmmaker. Likewise for FreeType constants, where
>> it is very obvious that adding the entire package can be problematic on
>> occasion.
>>
>> Ideally the packaging system ought to be able to deal with single method
>> packages and bundling them as required for specific needs. I'm not arguing
>> that that is necessarily a good way to do it but the mechanism ought to
>> make possible. Why would it matter to the loader whether the thing being
>> loaded is a single file of a gazillion methods or a gazillion files of one
>> method?
>>
>> tim
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131115/f0b962b1/attachment.htm