Pre-antialiased bitmap fonts

[dar02]

Comparing to the default iPod Video skin, all Rockbox skins look not nice because of it's monochrome(1-bit) sharp fonts.
I think it would be nice to improve the fonts quality to pre-antialiased bitmap fonts.

[torne]

Rockbox currently only supports 1-bit fonts. You would need to implement the actual code to render the font, not just provide an example of what it should look like

[soap]

preanti-aliased fonts would by nature be background-color specific.

[pabouk]

preanti-aliased fonts would by nature be background-color specific.

No. Pre-anti-aliased font could (and I think should) be implemented as a mask with one extreme value (e.g. 0) representing foreground only while the other extreme value (e.g. 255) representing background only. The values between would represent the appropriate blend between the foreground and the background which are not limited to be just plain colours but also arbitrary bitmaps. To save space we could use 4 or 2 bits per pixel instead of 8 for the mask. The question is how resource intensive would this feature be on various players.

If I remember correctly this feature has already been discussed in this forum.

[saratoga]

preanti-aliased fonts would by nature be background-color specific.

No. Pre-anti-aliased font could (and I think should) be implemented as a mask with one extreme value (e.g. 0) representing foreground only while the other extreme value (e.g. 255) representing background only.

Which means they're anti-aliased at run time, and not in advance

The values between would represent the appropriate blend between the foreground and the background which are not limited to be just plain colours but also arbitrary bitmaps. To save space we could use 4 or 2 bits per pixel instead of 8 for the mask. The question is how resource intensive would this feature be on various players.

If I remember correctly this feature has already been discussed in this forum.

This is just normal anti-aliasing.  Theres a patch on the tracker for it now.

[pabouk]

preanti-aliased fonts would by nature be background-color specific.

No. Pre-anti-aliased font could (and I think should) be implemented as a mask with one extreme value (e.g. 0) representing foreground only while the other extreme value (e.g. 255) representing background only.

Which means they're anti-aliased at run time, and not in advance

No again
Anti-aliasing is means of representing a higher resolution (possibly infinity in case of vector fonts) signal into a lower resolution signal with minimized sampling artefacts. The masks as I described them above would be in the final resolution thus pre-anti-aliased. Only mixing with a background at the final resolution would be performed at run time.

The values between would represent the appropriate blend between the foreground and the background which are not limited to be just plain colours but also arbitrary bitmaps. To save space we could use 4 or 2 bits per pixel instead of 8 for the mask. The question is how resource intensive would this feature be on various players.

If I remember correctly this feature has already been discussed in this forum.

This is just normal anti-aliasing.  Theres a patch on the tracker for it now.

What do you mean by normal anti-aliasing? If the fonts are stored as bitmap masks in the final resolution the aliasing has been performed in advance and the fonts are pre-anti-aliased.

The main disadvantage of the result of this technique is that the letters cannot be positioned at sub-pixel resolution if we do not pre-compute such renderings. For example half pixel positioning in both horizontal and vertical direction would need four font renderings instead of one.

I searched the patches. Here you are: FS#8961 - Anti-Aliased Fonts.

Edit: Later I realized that practically the sub-pixel positioning is needed only in horizontal position for nicer (more exact) letters spacing. This reduces the number of renderings to two for half pixel resolution.

[saratoga]

preanti-aliased fonts would by nature be background-color specific.

No. Pre-anti-aliased font could (and I think should) be implemented as a mask with one extreme value (e.g. 0) representing foreground only while the other extreme value (e.g. 255) representing background only.

Which means they're anti-aliased at run time, and not in advance

No again
Anti-aliasing is means of representing a higher resolution (possibly infinity in case of vector fonts) signal into a lower resolution signal with minimized sampling artefacts. The masks as I described them above would be in the final resolution thus pre-anti-aliased.

If its done in advance, why do you have to change rockbox at all?  Just antialias the font files themselves.

Answer:  because what you're actually suggesting is to apply the filtering at run time.  The process you call "blending" is more commonly referred to as an "anti-alias filter".  All you're computing in advance is the filter itself, at runtime you still have to actually apply it.   

Take a look at the BLEND_* macros in that patch.  Note that they are FIR filter taps

[pabouk]

I think we start to get far from the original subject of the thread

If its done in advance, why do you have to change rockbox at all?  Just antialias the font files themselves.

I do not know all details of Rockbox features but as far as I know Rockbox uses only bitmap fonts with 1 bit per pixel. This cannot be used for blending the anti-aliased font edges with a background. Alpha mask bitmap fonts with more than 1 bit depth and alpha blending routines have to be implemented.

Answer:  because what you're actually suggesting is to apply the filtering at run time.  The process you call "blending" is more commonly referred to as an "anti-alias filter".  All you're computing in advance is the filter itself, at runtime you still have to actually apply it.

I did not call any action "blending". I utilized the word "mixing" because of my poor English. But you are right. The run-time process I described seems to be correctly called alpha blending or more generally alpha composition. I am not sure if such combining of multiple signals together could be called filtering.

I think that there is a big misunderstanding. Anti-aliasing has to be applied before or during signal conversion to a lower resolution / sampling frequency. See spatial anti-aliasing. If the fonts should be pre-computed as bitmaps at the final resolution (to minimize CPU usage at runtime) then the anti-aliasing has to be done when creating the bitmaps. Displaying of such pre-rendered and pre-anti-aliased fonts at run time is just combining of background and foreground bitmaps / colours using alpha blending with the pre-anti-aliased font bitmaps acting as alpha masks.

Take a look at the BLEND_* macros in that patch.  Note that they are FIR filter taps

I think that MAC operation can be used for many purposes. One of them is alpha blending.

[torne]

I did not call any action "blending". I utilized the word "mixing" because of my poor English. But you are right. The run-time process I described seems to be correctly called alpha blending or more generally alpha composition. I am not sure if such combining of multiple signals together could be called filtering.

Yes, you are technically right; the patch on the tracker is slightly misnamed, and the rendering process is just alpha blending. However, this is still an expenditure of CPU cycles at runtime in order to render antialiased fonts, which is what saratoga is trying to point out: we know how antialiasing works, but by calling it "pre-antialiased" it implies that the work to be done at runtime is trivial, and it's not really. I think he was just trying to emphasise that the approach you are suggesting is not a new idea, it's how people have previously tried to get antialiasing to work on Rockbox, and the existing patch for it is not currently acceptable. If you wanted this to get done, you would have to work out what's lacking in the existing patch and solve the outstanding issues.

[bk]

http://www.rockbox.org/wiki/FontSystemProposal

(circa 2007)

Figure out a way around the malloc() issue and you're 50% there.

[dryrock]

I have to say, I applied the font patch referenced above (8961) and it makes a HUGE difference in the appearance of text. I'm not sure about it's technical limitations and why it's not part of the standard build, but what I am sure of is that it goes a long way toward making the UI prettier, which does make a difference to a lot of people!

Now that I have a development environment set up I hope to be contributing some changes, but this one is beyond my skills -- hopefully the right person will come along soon.