Ned, apologies for not responding to all content you provide,

----- Original Message ----- 
From: "Ned Konz" <ned at squeakland.org>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, December 03, 2004 9:54 AM
Subject: Re: 3.8 UI performance drop?


> On Thursday 02 December 2004 6:34 pm, Lyndon Tremblay wrote:
> > 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.
>
> I am currently working on a plugin for the Cairo 2D graphics library, and
> through that the Freetype/2 text rendering library.
>

Oh wow, I am very curious here! (GNUstep is also preparing for a Cairo
backend). Though I thought it was just 'Cairo' and think it does not contain
anything non-2D.

> I have done prior work with Freetype/2, and have found that its caching
works
> quite well.
>
> I'm seeing that text rendering is actually faster (and much better looking
> because of glyph hinting) using Cairo than even the bitmap fonts.
>
> Actually, the TrueType font support that Yoshiki did and that is in the
image
> currently is quite fast, as long as you don't have multi-colored text.
>
> The problem is that he's caching each colored glyph separately -- so for
> instance a red "a" will displace a black "a" in the cache, and then will
> require re-rendering of the whole cached glyph (from the original curves).
>

Similar to how GNUstep stores rich text, it stores about 4x the

> It should be possible to change the existing TrueType font support so that
it
> either caches differently or re-colors the glyphs before compositing them
> with the destination bitmap.
>
> That is, what's happening now is that what is cached is a 32-bit Form of
the
> right color, with varying alpha levels:
>

Eek.

> (cache at: charCode) holds color->form
>
> this is displayed using BitBlt mode 34 (the scaled alpha blending mode).
>
> However, we could easily cache a white glyph with varying alpha levels,
and
> first use that to make a colored glyph form and then use mode 34 as
before.
>
> This would be faster than drawing a brand new glyph from the curves every
time
> we change color. Of course, it would slow down each character drawn in the
> more general case where the text was the same color.

This is nice, and natural to state-based pipes ala OpenGL. (color modulation
for a grayscale 'mask' image). I think the case of monocolored text data can
be optimised specially, too.

>
> This is what I did for the non-plugin version of the Freetype/2 fonts (in
> fact, try out that package from SqueakMap and see if it isn't faster and
> better looking with these multi-colored fonts).
>

Hmm I will play with this implementation.

> The advantages of this technique include:
>
> * reducing the memory required for the cached glyph forms by a factor of 4
> * letting us save a single cached glyph instead of one per color, thus
saving
> the expense of re-rendering every time the color changes
>

I thought this is how it would have been done from the first implementation,
seriously. It is actually simpler in various ways.

> Actually, looking back at that code, what I did was to use mode 24
> (alphaBlend) when the destination was a 32-bit deep Form, and the two-step
> process described above if the destination was a 16-bit deep Form.
>

Hmm...

> So the BitBlt installFT2Font:foregroundColor:backgroundColor: in the
32-bit
> deep case (the faster of the two) looked like:
>
> backgroundColor := text background color
> foregroundColor := text foreground color
> sourceForm := pre-rendered glyphs (an 8-bit-deep alpha-only form)
> colorMap := (possibly cached) colormap that maps values from 0..255 to
solid
> colors in the range of backgroundColor..foregroundColor
> combinationRule := 34
>
> and then to display a string using that FT2Font, just:
>
> nonPrimDisplayFT2String: aString from: startIndex to: stopIndex map:
glyphMap
> aTable: aTable oTable: offsetTable xTable: xTable kern: kernDelta
>  | ascii glyph |
>  startIndex
>   to: stopIndex
>   do: [:charIndex |
>    ascii := (aString at: charIndex) asciiValue.
>    glyph := glyphMap at: ascii + 1.
>    sourceX := xTable at: glyph + 1.
>    width := (xTable at: glyph + 2 ifAbsent: [ sourceForm extent x ]) -
> sourceX.
>    destX := destX + (offsetTable at: glyph + 1).
>    self copyBits.
>    destX := destX - (offsetTable at: glyph + 1).
>    destX := destX + (aTable at: glyph + 1) + kernDelta]
>
>
> Another, probably better fix (but one that requires plugin support) is to
add
> one or two BitBlt modes that would let us keep 8-bit (for non-subpixel
> rendering) or 24-bit (for subpixel rendering) deep Forms that store just
the
> alpha value.
>
> Then the operation would be something like:
>
> destination := ((1-srcAlpha) * destination) + (srcAlpha * color)
>
> with the computation being done for each color component separately.
>
> This would also enable us to use subpixel rendering with LCD displays (but
> that requires 24-bit deep cached glyphs, a font engine that knows how to
do
> SPR, and a new BitBlt mode)
>

o_o My familiarity of Squeak's display system is still just a bud,
unfortunately - I can't spend too much attention here. (Depth dependance is
similar in cost to resolution dependance...)

>
> Anyway, if someone is up to it, improving the existing TTCFont to use this
> technique would be pretty easy, and you can grab my code from the FT2Fonts
> package on SqueakMap.
>
> And see if that FT2Fonts don't speed up Shout (and make it look better).
>
> -- 
> Ned Konz
> http://bike-nomad.com/squeak/
>

I will now do this right away.

Thanks,
-Lyndon