On Mon, 28 Dec 2015 21:35:11 +0100 Michal Suchanek <hramr...@gmail.com> said:
> 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 you can get RGB, BGR etc. in edid - this is not always correct, and when it's not - boom. stuff is not happy. evas itself is unaware of edid info or screen info like dpi etc. - its higher layers that deal with this. > 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. yup. have 2 monitors with different layouts. boom. :( that was my point - this falls apart way to quickly and when it does the results are staggeringly horrible, > > 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. that is more sensible than rendering the font itself with rgb anti-aliasing. then it applies to all content equally AND means that if you move a window from a normal to a hi dpi screen... it can actually seamlessly "look good". of course there is an issue here - then you spend either 2x2, 3x3 or 4x4 etc. the cost in rendering (it is NOT cheap) as well as in memory footprint. (4 times, 9 times or 16 times the memory needed and the bandiwdht and the rendering horsepower) > > 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. yup. thats a big reason to just say no today. with high dpi becoming increasingly common (still not common but on its way) it isn't worth it. given all the downsides it isnt even worth considering imho. :( > 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. it has been a long long time since i ever saw x report a FIXED dpi: 9:05AM ~ > xdpyinfo | grep resolut resolution: 108x107 dots per inch thats the old school dpi (where you have one across an entire root window which isn't actually really true with randr where different screens of different physical size and resolution can look at areas of a single root). xrandr can report physical size (if the monitor provides it). the issue is more in the hands of toolkits where they either dumbly use the global dpi value, or a dpi value in a config files somewhere rather than what x says. they do this because of my other mail. people say "oh just set dpi to xxx" to make things bigger. thus to make ti simple they use a separately configured dpi value, which is wrong. efl takes a different view on this. we have a scale factor. this just multiplies sizes by X where X can be 1.0, 0.8, 1.1, 1.2, 1.5, 2.0, 3.243 etc. - and elementary uses a specific profile. e can ASSIGN a different profile per screen, per virtual desktop. each profile can have a different scale factor. elm based apps will in fact do this and switch profile when e tells them to. the idea is not to JUST do scaling, but to handle screen type eg a touchscreen vs a normal desktop screen, so you may move from touch/finger driven mode to pure mouse driven mode etc. e currently doesnt have away to have a "base profile" and then auto generate different ones per screen and adjust the scale factor based on dpi - we dont have that automagic code (yet). i should add that at some point when i get the time. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
