On 27 December 2015 at 23:27, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sun, 27 Dec 2015 16:59:33 +0100 Stanislav Baiduzhyi > <baiduzhyi.de...@gmail.com> said: > >> I've noticed that fonts in EFL-based apps are not as good as in Qt >> apps, and digging into source it looks like LCD rendering is not >> supported, render mode is hardcoded to FT_RENDER_MODE_NORMAL. Is that >> intentional or just not yet implemented feature? > > 100% intended. there is no way we are doing that insanely bad sub-pixel rgb > stuff n efl. an explicit decision to not support it. why? > > 1. 3x the storage needed at least for fonts > 2. slower rendering > 3. adds colorization/swimming artifacts so it's not "better" just it gains > some > percieved resolution and loses color fidelity in the process (eg you willfind > the outline of a char may swim between reddish and blueish as it goes down a > diagonal). > 4. this requires metadata (the exact rgb pixel layout) that you can't always > accurately get and in the end needs to be manually provided > 5. in additon this falls down horribly when the rgb layout is wrong for your > screen - eg if its a pentile amoled or its bgr, or gbr, or perhaps there are > not 3 ditinct rgb triplets side by side - maybe its vertical or a projector > where there literally are not side-by-side elements byt they layer on top in 3 > display passes (r, g then b).
That's unfortunate that displays do not include this information in EDID or such. Still there are ways to specify the correct order, even ones that don't require the user to be a rocket scientist. eg windows have a wizard which basically renders the text with every setting available and lets the user pick whatever looks the best. You have to do that for every display in multi-display configurations, though. > 6. this totally falls over once you do transforms - eg you rotate an object 90 > degrees or any angle for that matter or stretch etc. - eg via proxies or map > as well as entire window or screen rotation where your rgb layout is basically > changing on the fly. you have to recompute all your font sub-rendering every > time for the full 90 degree rotations and anything else is basically undoable > so you have to turn it off. And since compositing is becoming popular this antialiasing (subpixel or otherwise) should be done in the compositor. Unfortunately, the compositor does not have the subpixel information because the window is usually rendered pixel for pixel. So if you really wanted subpixel rendering that badly you can probably add an experimental feature to your compositor so it reports the DPI larger to applications (eg 3x or 9x) and then scales down the rendered window bitmaps using any hacks you like. You might need special hacks for single pixel lines, though. > 7. historically such "hacks" have limited lifespans as display technology > keeps changing, i've lived through many such hacks across 8/6 and 32bit > machines over the decades. i've seen hacks come and go. thus code invested in > this even with the above issues will have a limited lifespan and add cost to > maintain. Indeed, with higher res displays antialiasing in general and subpixel rendering in particular is losing its sheen. On 28 December 2015 at 20:39, Stanislav Baiduzhyi <baiduzhyi.de...@gmail.com> wrote: > On Sun, Dec 27, 2015 at 11:27 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: >> 100% intended. there is no way we are doing that insanely bad sub-pixel rgb >> stuff n efl. an explicit decision to not support it. why? > > That makes some sense. Pity, on still very popular 96 DPI monitor > readability of subpixeled font is one step higher. Popular in the sense you can easily pull a working one from the trash? > > Also, I've noticed that font size is often configured in pixels and > not in points, why? > It's stupid. On the other hand, X reports DPI as 96 always unless you take manual measures to correct it. There is also per-display DPI which you can infer from xrandr information which is also often bogus. And nobody probably bothers to read it anyway. Thanks Michal ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
