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.

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).

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:

(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 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).

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

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.

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)


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/