On 29 December 2015 at 01:11, Carsten Haitzler <ras...@rasterman.com> wrote: > 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. >
There was actually long-standing bug in X where it would meticulously calculate the DPI based on the actual pixel size and then throw out that value and just say 96. Now that seems fixed $ xdpyinfo | grep resol resolution: 94x94 dots per inch so we are probably back to the problem that when you change screen layout X tries to do something smart with the global DPI value and due to rounding errors that add up your DPI can become arbitrarily large or small after repeated xrandr operations (like changing display modes, logical arrangement, or turning screens on and off). Not all these operations are completely voluntary. Some programs like to turn off displays other than the one on which they run and want to change it to a particular display mode and when you unplug a display physically it has to be turned off. The getting DPI from the xrandr stuff is not that easy for applications: DVI-I-1 connected primary 1200x1600+1200+0 (normal left inverted right x axis y axis) 324mm x 432mm 1200x1600 59.96*+ HDMI-1 connected 1200x1600+0+0 left (normal left inverted right x axis y axis) 408mm x 306mm 1600x1200 60.00*+ Note that with this driver the screen size in mm matches the display mode (on a separate line) but some drivers (used to?) swap the mm sizes to match the rotated output dimensions as shown on the same line as the mm dimensions. Note also that you have an actual screen with portrait mode here so you *cannot* assume that screens are landscape. Matching the longer physical dimension with higher value in the display resolution may fail for screens with _very_ non-square pixels. The fact that I haven't seen one does not mean one does not exist :s Also all in all DPI is not really that interesting. What you want is expected viewing angle of a pixel. When you compare desktop display with desktop display comparing their DPI you get also the comparison of the (inverse of) viewing angle of a pixel. This breaks when you have TVs, desktop displays, laptop displays and phone displays. That's why some (most?) TVs lie about the DPI. There is nothing for viewing distance (or the zoom factor) in the EDID. Well, if zooming was standardized across systems and desktops and easy to do with any of touch, mouse, and keyboard you could just let the user to set the zoom factor by hand, heh. Thanks Michal ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
