Bug 106219 - RBGA Order options for moden panels (Pentile, RGBG, OLED)
Summary: RBGA Order options for moden panels (Pentile, RGBG, OLED)
Status: RESOLVED MOVED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-24 15:26 UTC by Redsandro
Modified: 2018-08-20 21:48 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Subpixel pattern for Lenovo OLED screens (1.29 MB, image/png)
2018-04-24 15:26 UTC, Redsandro
Details
Font Hinting Options (27.59 KB, image/png)
2018-04-24 15:27 UTC, Redsandro
Details

Description Redsandro 2018-04-24 15:26:00 UTC
Created attachment 139058 [details]
Subpixel pattern for Lenovo OLED screens

* Cinnamon version 3.4.6
* Distribution - Mint 18.3 x64

There are no RBGA Order options for moden panels (Pentile, RGBG, OLED etc) in Font Settings.

Raised here: https://github.com/linuxmint/Cinnamon/issues/7107
Redirected to freedesktop/fontconfig.

Lenovo Yoga Carbon OLED, for example, has pixels that could be simplified as:

RB
GB
Comment 1 Redsandro 2018-04-24 15:27:29 UTC
Created attachment 139059 [details]
Font Hinting Options
Comment 2 Behdad Esfahbod 2018-04-24 19:56:03 UTC
Unless someone has figured out a way to optimize rendering for those specific panels, there's no need to add them.
Comment 3 Redsandro 2018-04-24 22:25:23 UTC
@BehdadEsfahbod where do I open an issue for this? I can figure out a way at least for the type of OLED I have and can measure. I just need to know how and to whom I communicate my observations.

The algorhythm will be similar, it's just the layout that's different.

For RGB or BGR the horizontal resolution is rendered 3 times more dense, and the respective R, G and B values of those pixels are mapped to the subpixels of a single pixel.

For vertical RGB or BGR the vertical resolution is rendered 3 times more dense, and respective subpixel values are mapped to a single pixel.

For R 
    G B the resolution needs to be rendered 2 times more dense, horizontally and vertically.

I can investigate with a microscope, as I have done in the attached picture.

But if this is the wrong place, I'm hoping someone can point me in the right direction.
Comment 4 Behdad Esfahbod 2018-04-24 22:43:09 UTC
My gut feeling is that these new panels are high-resolution enough that subpixel rendering is not necessary. I'm also worried about the color fringing you would get with those panels.  It's already bad enough that with regular Pentile displays you a visible zigzag of red on the right side of the vertical stems. That's why I believe Android does a lot more blurring to work around that. Ie, it's lowpass-filtering the image. Extra resolution wouldn't help that; it will be filtered out.

If you still want to try, you can play with FreeType. Microscopic image is irrelevant. The question is: does it look significantly better than just grayscale antialiasing.
Comment 5 Redsandro 2018-04-25 11:27:07 UTC
I'm using the grayscale antialiasing, because the RGBA has terrible fringing (due to the mismatch in subpixel layout).

However, text in grayscale antialiasing is fringing too - green on top and red on bottom.

I think the answer to "does it look significantly better" depends on who you ask. Perhaps a designer would say yes more often than a programmer.

Playing with freetype only makes sense if I can insert a custom rasterization matrix somewhere. And in order to figure out this matrix, I need to investigate the subpixel layout. Microscopic image is not irrelevant, unless you propose a bruteforce approach to finding the optimal matrix.

Aside from fonts, I'm also interested to see if there are facilities for pixel-precise postprocessing when rendering the desktop, since thin horizontal lines also have fringing. Basically every hard edge on a dark block on a light background is green on top and purple on bottom. A subpixel-aware opposite of sharpening would fix this.

I have the eye, the equipment and a theoretical understanding of what needs to happen. I don't have the technical understanding of where I can try this out or whom to talk to; as in someone who is interested in improving this too.

So I'm guessing I should take this issue to the freetype bugtracker? If it comes to an implementation, I go back here?
Comment 6 Alexei Podtelezhnikov 2018-04-25 19:54:35 UTC
I know what to do theoretically for such weird pixel geometry, see brief summary how Harmony LCD rendering works [here](http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=410f3799b6a193e20b34c574e6f0f2be2428b1eb). You need to combine LCD image from three separate grayscale images, each of which is obtained after slightly shifting the outline. The shifting direction should be opposite to the location of the color channel relative to the center of the whole pixel. 

It is actually not that hard. Should FreeType provide an API for that is a big question.
Comment 7 Alexei Podtelezhnikov 2018-05-02 15:56:15 UTC
If you own a monitor with unusual LCD pixel layout, I have posted a broad call for testing:

http://lists.nongnu.org/archive/html/freetype/2018-05/msg00006.html
Comment 8 Redsandro 2018-05-02 21:17:29 UTC
I'd like to point out that I do perceive this as an improvement.

https://savannah.nongnu.org/bugs/index.php?53749

Here's to hoping that this will be an option on GNOME/Cinnamon at some point.
Comment 9 GitLab Migration User 2018-08-20 21:48:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/63.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.