about "sub-pixel rendering"
------------------------------------
I wish I'd had the time to research this more, and I may try to put together
a report about it, but in the meantime maybe some links and a bare outline
will suffice.
"sub-pixel rendering" is the utilization of the red, green, and blue pixels
of a display as seperate entities (seperate pixels), and not as
three-in-one.
it gives a better resolution for the same number of horizontal and vertical
pixels.
it doesn't bring the bluring caused by anti-aliasing.
for a full explanation of it, please the pages linked from:
http://grc.com/cleartype.htm
to jump straight to some technical info about how it works:
http://grc.com/cttech.htm
possibly of direct interest for the palm:
"Optimising LCD display of text"
http://oxy.sfx.co.nz/lcdtype/
the implementation used by microsoft:
http://www.microsoft.com/typography/cleartype/default.htm
(can be used, or made to be used, on winCE ?)
more information about it, and related to the microsoft implementation:
http://www.peda.com/info/hypetype.html
<excerpt from="the peda.com link">
Q. Would this be difficult to implement?
A. The difficulty would be comperable to adding anti-aliasing to an existing
rendering architecture (as Apple has done with MacOS 8.5). The problems with
doing this sort of thing (anti-aliasing, or sub-pixel rendering in general)
is that the API is not designed for it. Application/OS communication is
often done in terms of pixels (not sub-pixels) so kerning/endpoint placement
cannot easily be improved and rendering may not be faithful to intent.
Background images must be taken into account, and true sub-pixel geometry is
normally not stored, so occlusion cannot easily be improved. The easy way of
doing this sort of thing is to render (using pixel-based rendering) a higher
resolution image and then resample it for display. The primary disadvantage
is that this is slow, and not a true solution (true sub-pixel coverage is
still not stored, only better approximated )
</excerpt>
if anyone knows if this does, or might be made to, apply to the palm pilot,
please drop a line about where I should look, to possibly start working on
it.
I'm guessing that sub-pixel rendering might cause even more of a
battery-vamp than the current PDA color displays apparently are, but maybe
the info will be helpful anyway.
and maybe some work with assembler might help both methods to be more
efficient ?
--Sean Champ
<postscript>
...does anyone know if this is what is used by HDTV ?
</postscript>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
