November 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] ArrayedCollection, Boolean SmallInteger>>ccg: cg generateCoerceToOopFrom: aNode on: aStream

by StÃ©phane Ducasse

I have the impression that we could remove these methods from the images. It seems that this is related to the VM generation? Does someone know more about them? Stef ccg: cg generateCoerceToOopFrom: aNode on: aStream self instSize > 0 ifTrue: [self error: 'cannot auto-coerce arrays with named instance variables']. cg generateCoerceToObjectFromPtr: aNode on: aStream

Nov. 5, 2008

Re: [Pharo-project] some minor tuning

by StÃ©phane Ducasse

Yes scanning all the memory at startup is not really exciting. I will add an entry to the issue list Thanks john. Stef > > I see we still do the forgetAllGrabCommandsFrom: dance across all > objects in the image at startup time, > not sure if this issue was ever resolved.

Nov. 5, 2008

Re: [Pharo-project] FreeType

by Gary Chambers

It would be a start, though, as I indicated, the major problem is the large computational expense of rendering the cached glyphs. Regards, Gary. ----- Original message ----- _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2008

Re: [Pharo-project] FreeType

by David Pennell

Changing the cache management policy and enhancing the mapping of logical to real fonts seem like relatively low hanging fruit or am I missing something? -david On Wed, Nov 5, 2008 at 11:19 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: [snip] > Currently, if the cache size limit (bytes of all glyph forms in the cache) > is hit the cache resets totally and subsequent requests will regenerate the > needed glyphs. > > Upping the FreeType glyph cache limit helps though the fact that two > different instances of a LogicalFont (with the same parameters) will create > a new real FreeTypeFont, the cache tends to churn. >

Nov. 5, 2008

Re: [Pharo-project] FreeType

by Gary Chambers

Having said all that, FreeType is a must. The font quality is awesome. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, November 05, 2008 4:57 PM Subject: Re: [Pharo-project] FreeType >I do not know anything about fonts > can you explain the cache mechanism for the font rendering? > briefly? > > Stef > > On Nov 5, 2008, at 4:20 PM, Gary Chambers wrote: > >> Hi all. >> >> Using the latest FreeType (admittedly on a 3.9 image, though probably >> generally applicable) we are noticing quite a lot of cache thrash, >> meaning that the low-level glyph rendering is happening quite often. >> >> Really noticeable on slow machines (our deployment target has 800MHz >> processors). >> Was wondering if it might me a good idea to move the cached form >> rendering into a plugin (lots of bit manipulation in Squeak code loops)? >> >> We've stabilised thing for the moment by hanging onto the LogicalFonts >> used and modifying the real font lookup to reuse existing matches and >> switching to CRT mode (3 times quicker). First use of glyphs at varying >> subpixel positions miss the cache though. >> >> Regards, Gary. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2008

Re: [Pharo-project] FreeType

by Gary Chambers

Looking at the latest FreeType, glyphs are cached (as forms) for each real font looked up by a LogicalFont. Two different instances of LogicalFont that happen to match actually has a second instance of real font. Aside from that, the glyph cache contains entries (for a real font instance) for any used character/sub-pixel-position/colour combination. The creation of the cached glyph forms is quite computationally expensive (as written in Squeak). So, from a logical font, asking for its real font will (lazily) (at present) load a new instance of FreeTypeFont, asking for a glyph (character) at a particular sub-pixel position and colour will look up in the cache and, if not present, create the form for it. Given kerning etc, up to 64 sub-pixel positions may be involved for each glyph. Currently, if the cache size limit (bytes of all glyph forms in the cache) is hit the cache resets totally and subsequent requests will regenerate the needed glyphs. Upping the FreeType glyph cache limit helps though the fact that two different instances of a LogicalFont (with the same parameters) will create a new real FreeTypeFont, the cache tends to churn. Given the multiple potential subpixel positions it is impractical to pre-cache all the glyphs for a font, hence there is a perfomance hit on first use of a glyph at a particular sub-pixel/colour point. Moving the low-level glyph rendering loops into a plugin will help the performance immensely. Sorry, there is no "briefly" :-) Regards, Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, November 05, 2008 4:57 PM Subject: Re: [Pharo-project] FreeType >I do not know anything about fonts > can you explain the cache mechanism for the font rendering? > briefly? > > Stef > > On Nov 5, 2008, at 4:20 PM, Gary Chambers wrote: > >> Hi all. >> >> Using the latest FreeType (admittedly on a 3.9 image, though probably >> generally applicable) we are noticing quite a lot of cache thrash, >> meaning that the low-level glyph rendering is happening quite often. >> >> Really noticeable on slow machines (our deployment target has 800MHz >> processors). >> Was wondering if it might me a good idea to move the cached form >> rendering into a plugin (lots of bit manipulation in Squeak code loops)? >> >> We've stabilised thing for the moment by hanging onto the LogicalFonts >> used and modifying the real font lookup to reuse existing matches and >> switching to CRT mode (3 times quicker). First use of glyphs at varying >> subpixel positions miss the cache though. >> >> Regards, Gary. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2008

Re: [Pharo-project] FreeType

by StÃ©phane Ducasse

I do not know anything about fonts can you explain the cache mechanism for the font rendering? briefly? Stef On Nov 5, 2008, at 4:20 PM, Gary Chambers wrote: > Hi all. > > Using the latest FreeType (admittedly on a 3.9 image, though > probably generally applicable) we are noticing quite a lot of cache > thrash, meaning that the low-level glyph rendering is happening > quite often. > > Really noticeable on slow machines (our deployment target has 800MHz > processors). > Was wondering if it might me a good idea to move the cached form > rendering into a plugin (lots of bit manipulation in Squeak code > loops)? > > We've stabilised thing for the moment by hanging onto the > LogicalFonts used and modifying the real font lookup to reuse > existing matches and switching to CRT mode (3 times quicker). First > use of glyphs at varying subpixel positions miss the cache though. > > Regards, Gary. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 5, 2008

[Pharo-project] some minor tuning

by John M McIntosh

I posted lessMethodSendsInFontUsage-JMM.4.cs to http://bugs.squeak.org/view.php?id=2144 to avoid excessive msg sends to font data entities as you resolve what to do character by character. Most of the changes described in #2144 were in Pharo but not all. I see we still do the forgetAllGrabCommandsFrom: dance across all objects in the image at startup time, not sure if this issue was ever resolved. Lastly I note PluggableListMorph>>getList runs quite a bit when we display a browser window. I'm wondering here if there should be a subclass where you know the list elements are strings and you just make a copy of the collection, versus doing a collect: asStringOrText -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 5, 2008

Re: [Pharo-project] [OT] A True Pluggable Look-and-Feel

by StÃ©phane Ducasse

this is good but now the key question is how can we have a chance to produce something when nobody is payed for making pharo cool. At the end of the day this is the real question. So may be if we could reuse what vassili is doing while we still can do it is also interesting. Stef On Nov 5, 2008, at 4:15 PM, Torsten Bergmann wrote: > see http://blog.3plus4.org/2008/11/04/a-true-pluggable-look-and-feel/ > -- > Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit > allen: http://www.gmx.net/de/go/multimessenger > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 5, 2008

Re: [Pharo-project] [OT] A True Pluggable Look-and-Feel

by Gary Chambers

Pretty cool. ----- Original Message ----- From: "Torsten Bergmann" <astares(a)gmx.de> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, November 05, 2008 3:15 PM Subject: [Pharo-project] [OT] A True Pluggable Look-and-Feel > see http://blog.3plus4.org/2008/11/04/a-true-pluggable-look-and-feel/ > -- > Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: > http://www.gmx.net/de/go/multimessenger > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2008