Rockbox Development > Feature Ideas
Pre-antialiased bitmap fonts
pabouk:
--- Quote from: saratoga on July 25, 2010, 03:39:38 PM ---
--- Quote from: pabouk on July 25, 2010, 03:25:02 PM ---
--- Quote from: soap on July 25, 2010, 02:30:30 PM ---preanti-aliased fonts would by nature be background-color specific.
--- End quote ---
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.
--- End quote ---
Which means they're anti-aliased at run time, and not in advance :)
--- End quote ---
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.
--- Quote from: saratoga on July 25, 2010, 03:39:38 PM ---
--- Quote from: pabouk on July 25, 2010, 03:25:02 PM --- 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.
--- End quote ---
This is just normal anti-aliasing. Theres a patch on the tracker for it now.
--- End quote ---
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:
--- Quote from: pabouk on July 26, 2010, 09:17:16 AM ---
--- Quote from: saratoga on July 25, 2010, 03:39:38 PM ---
--- Quote from: pabouk on July 25, 2010, 03:25:02 PM ---
--- Quote from: soap on July 25, 2010, 02:30:30 PM ---preanti-aliased fonts would by nature be background-color specific.
--- End quote ---
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.
--- End quote ---
Which means they're anti-aliased at run time, and not in advance :)
--- End quote ---
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.
--- End quote ---
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 :)
--- Quote from: saratoga on July 26, 2010, 02:54:39 PM ---If its done in advance, why do you have to change rockbox at all? Just antialias the font files themselves.
--- End quote ---
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.
--- Quote from: saratoga on July 26, 2010, 02:54:39 PM ---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.
--- End quote ---
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.
--- Quote from: saratoga on July 26, 2010, 02:54:39 PM ---Take a look at the BLEND_* macros in that patch. Note that they are FIR filter taps :)
--- End quote ---
I think that MAC operation can be used for many purposes. One of them is alpha blending.
torne:
--- Quote from: pabouk on July 27, 2010, 10:42:38 AM ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version