Actually I've just run various tests in varying situations; smaller fonts
has more objects to draw. It is actually slower for the same sized Browser.
(Also less legible, 9 point from 12) Still becoming curious about general
text support on-the-whole for Squeak. It ties with my curiosity for
potential performance and optimisations (high level) for Squeak. ~~~~~

-Lyndon

----- Original Message ----- 
From: "Yoshiki Ohshima" <Yoshiki.Ohshima at acm.org>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, December 02, 2004 5:40 PM
Subject: Re: 3.8 UI performance drop?


>   Hello,
>
> At Thu, 2 Dec 2004 14:39:12 -0800,
> Ned Konz wrote:
> >
> > On Thursday 02 December 2004 2:18 pm, Jon Hylands wrote:
> > > I had major problems of this sort with Shout performance, so I stopped
> > > using it. I really like Shout, but it makes Squeak text editing so
slow as
> > > to be almost painful.
> >
> > I'd recommend doing things like syntax coloring in the background, and
> > committing the changes after a bit of a delay in typing.
> >
> > Another possible improvement is to only update the portion of the text
window
> > that is actually *changed* by typing, rather than redrawing the whole
text
> > for every keystroke (I'm not sure whether Shout already does this).
>
>   I don't know about Jon's setting, but in general, the TTCFont is
> much slower than StrikeFonts when the color change is involved.  And
> touches more and more memory especially in larger fonts.
>
>   The bar, rounded corner, etc. shouldn't be too much trouble compared
> with the text rendering.
>
>   Just a random thought,
>
> -- Yoshiki
>
>