3.8 UI performance drop?
ned at squeakland.org
Fri Dec 3 17:54:57 UTC 2004
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
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 |
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 ]) -
destX := destX + (offsetTable at: glyph + 1).
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
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).
More information about the Squeak-dev