• Status Closed
  • Percent Complete
  • Task Type Feature Requests
  • Category User Interface → Font/charset
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 7
  • Private
Attached to Project: Rockbox
Opened by Hellworm - 2007-08-31
Last edited by Marc_Guay - 2008-12-12

FS#7683 - fast anti alias and subpixel hinting

I know this has been closed before, but the arguments were simply wrong:
- Vector fonts are required for anti alias as much as for bw fonts: not at all! The only reason to use vectors is for variable size fonts, which I agree are overkill.
- Translucency is not required, only drawing one key color transparent is needed, which is supported.

The speed difference is propably not that big, I think (but I don’t quite understand the rockbox source code) that the speed change would be from using lcd_bitmap_transparent_part instead of lcd_mono_bitmap_part inf lcd_putsxyofs, which means drawing a native bitmap instead of bw. The real rendering would happen when caching the font: Then the bitmap font file would be loaded and the font would be rendered in the foreground color against a background in the background color. Only pixels which are completely transparent will then be set to the transparent key color.
On plain backgrounds, like they are used in many wps the appearance will be identical to real anti-alias. On background which have not much colors (which are used in most wps) the difference to real anti alias will propably be invisible.

The main drawback for this approach is the memory usage. It will increase 16 times for most targets. Which means its propably not applicable for large fonts. But since anti alias and especially subpixel hinting increase readability mainly for very small fonts this shouldn’t be a problem either.

Attached is a picture illustrating the differences between real and fast anti-alias on a variable backgound.
Note: To really see the difference you should copy the image to your player and examine it there.

Btw I don’t require rockbox to have anti alias, Its great without. And doesn’t necessarily need it. But it’s technical possible and the appropriate task shouldn’t have been closed. No problem if no one picks it up. Heck, I might at some time even try it myself when I finally understand the rockbox architecture (but that might take some years).

   alias.png (13.5 KiB)
Closed by  zagor
2008-12-12 15:24
Reason for closing:  Invalid
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Closing all feature requests.

I can’t actually see any difference there at all.

You need to zoom in…a lot:

Yes, I see that. But the point I’m making is that your original image is much closer to the original size of a DAP screen. So unless you’re whipping a magnifying glass out whilst on the bus, or holding the display an inch from your eyes - what would this change actually buy you in real world usage ?

That’s the old discussion about font rendering. Look at it on your DAP, I normally look at my h300 from half to third the distance than at my screen. I can see a clear difference, the letters are less jerky. But if you can’t see the difference or find it negligible then you don’t need AA.

I saw the difference on the non-zoomed pic on the first look.
I highly support anti-aliased fonts.

im inclined to close this because as you say its been rejected in the past… BUT.. seen as you say its technically feasible, and should be fast, ill leave this open in the hope a patch is attached… shouldn’t take more than 5 minutes right?

I want AA too, it will let one use more fonts that look better, as the majority of font on computers use AA.

Soaa commented on 2007-12-04 20:53

I think this would be a great feature, especially for players with bigger screens. Small fonts on small screens look better without antialiasing, but bigger fonts on bigger screens definitely look better with AA.

A way to limit memory usage would be to use grayscale rendering (no subpixel rendering) with less gray levels. 8 levels should be fine, so 3 bits per pixel? That’s only 3 times more memory.

Looking forward to this.

Definitely agree with this idea. Additionally, I agree that vector fonts would not be required and would be overkill.


Available keyboard shortcuts


Task Details

Task Editing