The chore of loading all 500 fonts on a macintosh, rendering them all to show what they look like, was *quite* expensive and added many 10's of seconds to Sophie startup time.
At first we dumped the entire font menu oops tree into a image segment. The did a merge process by checking the current machine's view of the fonts, versus our historical view. usually fonts don't change much so the cost was only reading the directory. This worked oh, 99.99% of the time. The 0.01% was the hassle. Our fallback was then to store the rendered form for each font in an image segment. That seemed to work 100% As pointed out there is just a mess of eToys/Projects/whatever special casing going on in the default storage/reading of the segments, and when it goes bad, it's *hard* to figure out why. I did explore this area a bit more with WikiServer. In fact it's still on my to-do list, you can customize/override things to get a more simplistic set of steps, but I wasn't quite sure that sending a Pier Wiki to an image segment would be readable in the future, so I decided not to offer that as a storage option. On 2009-12-08, at 3:04 AM, Henrik Johansen wrote: > > On Dec 8, 2009, at 11:33 20AM, Mariano Martinez Peck wrote: > >> >> >> Thanks John. I am interested in your experience. However, I didn't >> understand this last paragraph where you said to finally make it work. >> I don't understand what did you change. What is the difference between "font >> menu" and " stored forms of >> each font face for the menu" ? > The way I read it, instead of storing the fonts themselves in an image > segment, they stored a form with a string rendered by the font, then used > that to display in list instead of actually loading the font, and rendering > text with it. > That way the list could be shown fast, without having to load the fonts > themselves until actually used/fonts on the machine changes. >> >> In addition, do you know why this has solved the problems ? > > If you look at the relative complexity of TTCFont and Form instances, it'd > hardly come as a surprise that one may be loaded consistently, while the > other is harder to get loaded correctly in all cases... > In other words, to me it seems like a workaround for non-repeatable errors > when loading complex objects within ImageSegments (by storing simpler objects > instead). > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <[email protected]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
