How do you enable Font Anti-Aliasing and Sub-Pixel Rendering in BodHi?
I made a post about this ages ago.. but still having problems.. I thought I would bring the topic to the new forum....
I tried installing lxapearance but it did not seem to do anything?
In order to know how good you are at something requires exactly the same skills as it does to be good at that thing in the first place, which means that if you are absolutely no good at something at all, then you lack exactly the skills you need to know that you are absolutely no good at it." - John Cleese
I used to mess with "Font Anti-Aliasing and Sub-Pixel Rendering" but had mixed results and stopped doing it. Here it worth quoting Raster. Make of it what you will, but he clearly advises against it:
> One more question: for those of you using Redshift, did you notice that > Firefox and Chrome are not affected by it? The E apps have correct color > temperature but not GTK apps. > Also, can I use fontconfig to control the level of hinting and subpixel > antialiasing?
for efl, e has settings -> look -> font settings ->advanced -> hinting/fallbacks
for other apps/toolkits you will need to see relevant docs for those. efl doesn't do subpixel rendering. it will only do regular AA + hinting options. subpixel creates a whole host of new problems that probably has more downsides than upsides and at best are break-even
and one more:
> I am not sure that I agree > subpixel antialiasing creates too much trouble -- it is supported by many > DEs (I think all GTK and Qt based ones support it). The effects (probably > is subjective) is pretty good on non-retina screens.
1. you can't rotate ext once rendered without horrible color fringe artefacts. really bad when you want to support rotatable displays or windows or content. this applies to scaling up or down or any other kind of transform that is not 1:1 as originally rendered. 2. it already is a compromise - it gets a "possible theoretical higher res by assuming a simple [r][g] or [g][r] sub-pixel layout of the screen technology and fools the code into thinking r, g,b values are actually sub-pixels... but they are not. they are different colors and this leads to color swimming/fringing. it's so horrible that draw pure blue text and parts of the rendering can disappear if the sub pixel being drawn does not land on a blue sub pixel. so this falls apart quickly for colored text. otherwise it leads to visible color-fringing artifacts. 3. it falls apart if display is not [r][g]. e.g, if its pentile like: [r] [g] or if RGBW or any other kind of possible pixel layout. even worse you have multiple monitors with different sub pixel layouts and it gets even worse. 4. it makes rendering slower for fonts as you now have 3x the source data to read and also use more memory for them.
and some others i won't bother getting into but overall it's a big compromise in many many ways and quickly degrades the moment you step outside of a very basic defined set of behaviour. Given rising DPIs it just isn't worth the extra code complexity and hassle.
personally i notice sub pixel rendered text instantly - not that it's better but that i see swimming color fringes and reminds me of old tv's and vcr's with bad color fringing or chromatic aberration like: