-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bert Freudenberg wrote: | One thing that someone (Albert IIRC) proposed was doing a better | filtering job than the DCON does - it uses a simple 5-tap filter which | adds a noticeable amount of blur. It is still vital to do filtering, | otherwise a single red pixel surrounded by black background that | happens to fall on a blue physical pixel would not be seen at all, the | filter ensures that at least half of its energy is distributed to the | adjacent red physical pixels. Or a single white pixel would appear | colored.
This is precisely what I was talking about. Actually, it is possible to go one step further than improved filtering, and alter the contents of the display in response to the precise subpixel layout. This is essentially what subpixel font rendering does. It not only uses a many-tap filter to avoid local colorations, but also rerenders the fonts with a hinting scheme that is sensitive both to their subpixel alignment and to the filter that is about to be applied. Currently, the caps and feet on serif characters might be rendered as a single pixel, which is then blurred out by the deswizzling filter. If the font renderer were aware of this, it might be made to alter its rendering to increase the size of caps and feet. As I said before, I do not think this is important, useful, or likely to happen. It is, however, a fun exercise: if your software knew in advance which channel was actually going to be displayed at each pixel, what would its optimal strategy be? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEeOIUJT6e6HFtqQRAkenAJ9FKAvOqutjFJOA/LQ6vIjID60S9QCfbAe3 fniOgX8yCdyFNU/iZy4AqZ0= =q459 -----END PGP SIGNATURE----- _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel