What font smoothing does 4coder use, AA or sub-pixel? On another note, does anyone know how sub-pixel rendering works on high DPI screens where the LCD RGB ordering assumptions are no longer true? Do you dynamically switch your font smoothing technique and use AA for high DPI and sub-pixel for 96 DPI and assume that you're on an LCD display?
Edited by Blake Martin
on
Reason: Initial post
Right now 4coder only supporrts AA smoothing. Any application that supports sub-pixel smoothing should also support AA and try to figure out what will work for the user and monitor. For example on Windows each monitor can be calibrated for sub-pixel settings.
What calibration are you talking about? Is there an API for that kind of stuff in win32? I went looking a little while back and didn't see any useful information that you can get out of display devices, monitor info, etc. I see some vendor specific strings but that is about it.
Could you point me in the direction of some resources about font smoothing and the difference between aa and sub-pixel?
Thanks for the link, it was a good reference. Does the sub-pixel and aa rendering only apply from going from vector to raster (ttf -> bmp)? Are there other techniques to make fonts look nicer for the bitmap to screen stage?
Well, the idea here is that the raster (bmp) conversion is done at the final display resolution where there is a 1-1 relationship between internal pixels and screen pixels.
Otherwise, sub-pixel (as in LCD smoothing) doesn't really make sense, since a (255, 0, 0) is supposed to light up the first third of a pixel, etc. If you were to scale LCD-smoothed text up, that one pixel value would map to multiple pixels and you would get what you see when you zoom-in on pixels in an image editor, where you are left wondering why your text is rainbow colored.
Missing your target resolution with LCD smoothing is bad news bears (, as far as I know. I have never tested the results of bilinear filtering 64 pt down to 10, for example. I am just assuming it's not exactly correct). With normal AA, it's less of an issue because you assume that your target resolution (at your target DPI) is high enough that you don't need sub-pixel detail. In that case, you can render a high-resolution atlas, rely on hardware filtering to render down to the target resolution -- into a multisampled color buffer (2X, 4X, etc.) -- and then do the normal mutisample resolve into the target resolution. Again, this will have the effect of AA down to whole pixel resolution, not sub-pixel, but that's fine if you're rendering on a sufficiently high DPI display. If your display is around the default of 96 dpi, you're going to want sub-pixel if you can (if your dealing with an LCD display).
Also note that this conversation is different from sub-pixel positioning, which is just using floating point pixel coordinates to layout UI elements. At some point, at the end of your pipeline, those units need to get snapped to pixel boundaries to look good like Allen mentions in one of the 4coder jam vods.
EDIT: I just realized that this makes it sound like you need MSAA or something to get AA. You don't. Your rasterizer will hopefully provide anti-aliased output. Whether you re-rasterize on the fly for zooming/resizing or use an atlas is up to you.
Otherwise, sub-pixel (as in LCD smoothing) doesn't really make sense, since a (255, 0, 0) is supposed to light up the first third of a pixel, etc. If you were to scale LCD-smoothed text up, that one pixel value would map to multiple pixels and you would get what you see when you zoom-in on pixels in an image editor, where you are left wondering why your text is rainbow colored.
Missing your target resolution with LCD smoothing is bad news bears (, as far as I know. I have never tested the results of bilinear filtering 64 pt down to 10, for example. I am just assuming it's not exactly correct). With normal AA, it's less of an issue because you assume that your target resolution (at your target DPI) is high enough that you don't need sub-pixel detail. In that case, you can render a high-resolution atlas, rely on hardware filtering to render down to the target resolution -- into a multisampled color buffer (2X, 4X, etc.) -- and then do the normal mutisample resolve into the target resolution. Again, this will have the effect of AA down to whole pixel resolution, not sub-pixel, but that's fine if you're rendering on a sufficiently high DPI display. If your display is around the default of 96 dpi, you're going to want sub-pixel if you can (if your dealing with an LCD display).
Also note that this conversation is different from sub-pixel positioning, which is just using floating point pixel coordinates to layout UI elements. At some point, at the end of your pipeline, those units need to get snapped to pixel boundaries to look good like Allen mentions in one of the 4coder jam vods.
EDIT: I just realized that this makes it sound like you need MSAA or something to get AA. You don't. Your rasterizer will hopefully provide anti-aliased output. Whether you re-rasterize on the fly for zooming/resizing or use an atlas is up to you.
Edited by Blake Martin
on
Thanks for the clarification rationalcoder, yea, so if you're scaling your glyph bitmap rendered with sub-pixel, your going to get some weird artefacts. @Allen Do the size of the glyphs in 4coder get scaled to take account of the screen dpi?
Edited by Oliver Marsh
on