[squeak-dev] [Ann] Enhanced StrikeFonts (antiAliasing , subPixel AA)

Hi Folks,

If you update to the latest trunk, you'll load Graphics-jmv.53,
Morphic-jmv.138 and System-jmv.118. This is the support for anti aliased
StrikeFonts from Cuis. The new 'BitmapDejaVu' font of point size 9 is
set as default. I only included size 9 (reg, italic, bold, bold italic)
to avoid using too much space in the image. If people want, more sizes
can be added.

To do proper antialiasing / subpixel AA _without_ requiring new BitBlt
modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule.
Text looks very good, in any combination of font and background colors,
even at lower Display depths and / or glyphs depths.

By default underscore and caret are shown as in standard ASCII. If you
prefer the classic ST-80 left and up arrow, evaluate 'StrikeFont
useLeftArrow'. To go back to the default, evaluate 'StrikeFont
useUnderscore'. I also added 2 preferences #subPixelRenderFonts and
#subPixelRenderColorFonts (both default to true).

Andreas, thanks for all your help!

Comments are welcome.

Cheers,
Juan Vuletich

On Mon, Aug 03, 2009 at 06:52:47PM -0300, Juan Vuletich wrote: Nicely done, thanks for this!

FYI, I did encounter a couple of glitches in doing the update. First,
I got a dialog saying "the map is more than 10 days old" (or something
like that), which I think may come from SqueakMap. After redoing the
update, all was well.

I then tried the update again (starting with my original image), and
did not get the "more than 10 days old" dialog (presumably because
I had updated the map), but then I did get an error while loading
System-jmv.118, see attached png.

In both cases, re-doing the update makes everything work, and I have
the new Cuis StrikeFonts loaded now.

Thanks!

Dave

David T. Lewis wrote:
> FYI, I did encounter a couple of glitches in doing the update. First,
> I got a dialog saying "the map is more than 10 days old" (or something
> like that), which I think may come from SqueakMap. After redoing the
> update, all was well.

This appears to be happening when the flaps get recreated. I found that
the best thing to do is to say "No" and continue updating (I had no
problems afterwards).

Cheers,
   - Andreas

Juan Vuletich wrote:
> If you update to the latest trunk, you'll load Graphics-jmv.53,
> Morphic-jmv.138 and System-jmv.118. This is the support for anti aliased
> StrikeFonts from Cuis. The new 'BitmapDejaVu' font of point size 9 is
> set as default. I only included size 9 (reg, italic, bold, bold italic)
> to avoid using too much space in the image. If people want, more sizes
> can be added.

Thanks Juan, this is really great. If folks haven't tried it yet you
should - it does really make a difference (and I'll update a trunk image
  soon so that you get the nicer fonts out of the box). About more sizes
- I think the one additional thing I'd wish is a size suitable for
Window titles. It looks odd to have nice fonts in texts and lists (and
the chosen font is great for that) and then not-so-nice fonts for the
Window titles. I tried using the 9pt font for titles but it's just a wee
bit too small.

Other than that: Way to go!

Cheers,
   - Andreas

Hi!

Andreas Raab wrote:
> Other than that: Way to go!

First of all - superb work! And really nice to see how work from Cuis
enter squeak.org.

Just one silly question:

>> To do proper antialiasing / subpixel AA _without_ requiring new BitBlt
>> modes, I use RGBMul BitBlt rule, and a second pass with RGBAdd rule.

So... is this a better approach than adding new bitblt modes or is it
just equally fine? Just wondering, I have no knowledge in this area.

regards, Göran

Hi Goran,

Göran Krampe wrote:
It is not a silly question at all!

I've been playing with the idea of arbitrary depth StrikeFonts for about
2 years now. Until recently, my objective was to do the best that could
be done without requiring new plugins, even if far from perfect. Then,
in May, Andy Tween (the author of the new BitBlt rule) said in VM-dev:
"I believe that the existing bitBlt rules are insufficient to cover all
these circumstances, but I am happy to be proved wrong :)". So I started
thinking about it, and I realized they are indeed enough, and came out
with this two pass idea. BTW, black text only needs the first pass. So,
it is even faster than the new mode for black text.

So far, they give exactly the same result. The differences might appear
for Display depths of 8 bits and less (RGBMul / RGBAdd don't work there,
and I guess Rule 41 won't work either). Something I like of my approach
is how well it works even with 4bpp glyps (to save space), and the fact
it never uses extra glyph caches. It does all it magic with just one
glyph definition for each font/character, just like older StrikeFonts.
So memory consumptions is predictable, once the font is created, no more
objects are created. And there is no Weak / GC stress at all. On the
other hand, Rule 41 supports gamma correction. I really don't know how
important this might be for text.

BTW, this 2-pass idea could be used to render any kind of font (or any
kind of bitmap object). It could be useful for rendering TTCFonts and
FT2Fonts too, avoiding the need to create colored glyphs cache.

Cheers,
Juan Vuletich

> regards, Göran

Andreas Raab wrote:
:)

I have just updated the trunk again. I added 12pt and set it as default
for window titles (in bold). I also added 7pt. It takes little space and
it is great for pdas or if you have sharp eyes.

Cheers,
Juan Vuletich

Juan Vuletich wrote:
> I have just updated the trunk again. I added 12pt and set it as default
> for window titles (in bold). I also added 7pt. It takes little space and
> it is great for pdas or if you have sharp eyes.

Very cool. I noticed one small issue when I was trying to make screen
shots with the fonts: For black text, the resulting output doesn't seem
have the alpha channel set which leads to some odd effects like in the
attached image (notice however that the white-on-blue text looks fine).
You can kinda guess what it's supposed to look like when you load it
into Squeak and do a #fixAlpha on it but it would be good if we could
generate a "proper" alpha channel. Any ideas what might be causing this?

Cheers,
   - Andreas

Andreas Raab wrote:
You're right. It seems we need the second BitBlt pass even for black
text. Just added that to the trunk. I also added a preference,
#properAlphaForBlackText that defaults to true, but can be set to false
if performance is more important that correctness.

Note #1. This needs a rather recent VM, that includes my fixes to BitBlt
done in April. Your latest Windows VM is ok.

Note #2. If the trend is to fix the handling of alpha channel in the
image, at some point the fix to ignore Display alpha must be removed
from the Linux VM, to play well with composing window managers.

Note #3. The second pass stuff is done in GrafPort, but not in BitBlt.
Do you think it is better to move it up to BitBlt?

Cheers,
Juan Vuletich

Juan Vuletich wrote:
Ok. I moved the double pass up to BitBlt, to avoid loss of quality if
rendering without a GrafPort. I don't know if that is ever done, but
this way it is more consistent.

Cheers,
Juan Vuletich

Juan Vuletich wrote:
> You're right. It seems we need the second BitBlt pass even for black
> text. Just added that to the trunk. I also added a preference,
> #properAlphaForBlackText that defaults to true, but can be set to false
> if performance is more important that correctness.

Yeah, good choice. It turns out that there is a measurable performance
difference between single-pass and two-pass rendering (for example in
the browser benchmark). Is it possible to merge these specific two rules
into a single-pass rendering to retain the original single-pass performance?

> Note #1. This needs a rather recent VM, that includes my fixes to BitBlt
> done in April. Your latest Windows VM is ok.
>
> Note #2. If the trend is to fix the handling of alpha channel in the
> image, at some point the fix to ignore Display alpha must be removed
> from the Linux VM, to play well with composing window managers.

Yes, we should. It would be nice if we could actually control the alpha
correctly.

> Note #3. The second pass stuff is done in GrafPort, but not in BitBlt.
> Do you think it is better to move it up to BitBlt?

BitBlt, since it's used directly from StrikeFont and not via Canvas.

Cheers,
   - Andreas

Andreas Raab wrote:
>> Note #3. The second pass stuff is done in GrafPort, but not in BitBlt.
>> Do you think it is better to move it up to BitBlt?
>
> BitBlt, since it's used directly from StrikeFont and not via Canvas.

Or that's what he thought. It turns out this doesn't work since it
breaks WarpBlt (which relies on the exact layout of BitBlt). I suppose
*that* is the reason why GrafPort got invented to begin with (it always
felt strange to me since Morphic had both Canvas and BitBlt and should
be happy inbetween the two - but if adding state to BB isn't an option,
that would explain GrafPort).

In any case, I pushed the state vars back down to GrafPort (renaming
them in the process to avoid Monticello madness) and hopefully
everything is fine now. You'll have to use GrafPort to get two-pass
rendering but it won't break if you use BitBlt.

Cheers,
   - Andreas

Juan,

the new StrikeFonts look nicely crisp, but the letter spacing seems to  
be off. Compare this new to old rendering:





Can this be made more homogenous? The space after the "r" seems to be  
too large, and the sequence "lit" looks very uneven compared to the  
right, older shot.

Secondly, can the sub-pixel AA be disabled on the fly? It leads to  
visible color fringes when the subpixel layout does not match your AA.

- Bert -

Andreas Raab wrote:
Well, each uses a different colorMap, so it is a bit tricky. On the
other hand, for black text, the second pass really should not be
necessary. When we get this right (more below), then the price for the
second pass is only paid for colored text.

The second pass is currently needed because of a bug in BitBlt. The
following code
f1 := Form extent: 8@8 depth: 32.
   f1 fillColor: (Color r: 1.0 g: 1.0 b: 0.7 alpha: 0.7).
   f2 := Form extent: 8@8 depth: 32.
   f2 fillColor: (Color r: 0.5 g: 1.0 b: 0.7 alpha: 0.9).
   bb :=(BitBlt toForm: f1) sourceForm: f2; combinationRule: 37; copyBits.
   (f1 colorAt: 2@2)
should evaluate to  (TranslucentColor r: 0.501 g: 1.0 b: 0.494 alpha:
0.627), but answers Color transparent. The problem is in
#partitionedMul:with:nBits:nPartitions: as it ignores the last argument.
Will send a mail to VM-dev about this.

Cheers,
Juan Vuletich

Andreas Raab wrote:
I managed to add the behavior back to BitBlt without adding any instance
variables. It is a bit hacky, as
#displayString:from:to:at:strikeFont:kern: needs to assume that if rule
is rgbMul, a second pass is in order. I prefer this, as it would give
proper rendering when not using a GrafPort / MorphicCanvas.

If you don't object, I'll upload this to the trunk later today.

BTW, as I said in another message, once we fix rgbMul in BitBlt, the
second pass will only be needed for colored text.

Cheers,
Juan Vuletich

>
> Cheers,
>   - Andreas

Bert Freudenberg wrote:
I created the fonts automatically, from a sample rendered with FreeType,
using area each glyph uses. In this case, the $r has a very light blue
pixel at the topRight. I can modify the script to ignore pixels that are
too light when setting the bounds for the glyph, but I can not guarantee
perfect results unless glyphs are tweaked by hand.
>
>
> Secondly, can the sub-pixel AA be disabled on the fly? It leads to
> visible color fringes when the subpixel layout does not match your AA.
>

Sure. See Preference #subPixelRenderFonts.

Cheers,
Juan Vuletich

>
> - Bert -
>

Juan Vuletich wrote:
> I managed to add the behavior back to BitBlt without adding any instance
> variables. It is a bit hacky, as
> #displayString:from:to:at:strikeFont:kern: needs to assume that if rule
> is rgbMul, a second pass is in order. I prefer this, as it would give
> proper rendering when not using a GrafPort / MorphicCanvas.

Ah, very clever ;-)

> If you don't object, I'll upload this to the trunk later today.

Sounds good, just make sure you add a comment or else some people will
be horribly confused about what this is all about two years down the
road ;-)

> BTW, as I said in another message, once we fix rgbMul in BitBlt, the
> second pass will only be needed for colored text.

Yup, I also saw your message on vm-dev.

Cheers,
   - Andreas

On 05.08.2009, at 18:17, Juan Vuletich wrote:

Yes, under magnification I see thew problem ... oh well :)

>> Secondly, can the sub-pixel AA be disabled on the fly? It leads to  
>> visible color fringes when the subpixel layout does not match your  
>> AA.
>>
>
> Sure. See Preference #subPixelRenderFonts.


Hmm, this does not show up in the Preferences panel ... also, when I  
disable that, all pixels become full black, so this is unusable.

- Bert -

Bert Freudenberg wrote:
I'll play a bit with this for the next trunk update I do.


It should work ok, doing gray AA. It must be some problem we introduced
in one of the very last trunk updates. Will fix it. Expect a new version
in the trunk tonight.

Cheers,
Juan Vuletich

Hi Folks,

A new version of the new StrikeFonts is in the trunk.

Bert Freudenberg wrote:
I fixed it. I added an heuristic to the font build script, to discard
some very light pixels. It looks quite nicer! It will never be as
precise as a real TrueType renderer, as StrikeFont can't adjust kerning
based on the shape of glyphs. But it is better than before.

If you see some glyph that could use further tweaking, please tell.

I also made digits from $0 to $9 to be monospaced. This is nice when
looking at columns of numbers.

This is fixed too. BTW, if you're using gray AA and don't care about
getting subpixelAA anymore, you can do
     StrikeFont allInstances do: [ :f | f setGlyphsDepthAtMost: 4].
This will make the fonts use 4 bpp, i.e. 8 gray levels. (In Squeak,
Forms of 4bpp have 8 gray levels and 8 saturated colors). This is quite
enough for gray AA. And it will save a lot of space.

I also fixed the other issues pending. The dual pass is done at BitBlt
and not only GrafPort, and as no new ivars are added, WarpBlt works ok too.

Finally, the second BitBlt pass should not be needed for black text, but
it is needed right now due to a bug in BitBlt. I expect the VMs to be
fixed in a couple of months. Then, I can adjust the image code to avoid
the second pass if possible.

Cheers,
Juan Vuletich