~eliasnaur/gio

8 5

Text rendering on HiDPI screen

Details
Message ID
<76063d66-8885-e2ac-8a32-98de5314c60a@meessen.net>
DKIM signature
pass
Download raw message
Hello,

I could test the component example to evaluate text rendering with GIO 
of my iPhone and iPad, and the rendering is perfect. The iPhone is 
~400DPI and the iPad is 220 DPI. This is a screen capture from my iPad [1].

Someone tested the kitchen example on an iMac with 27" (5120x2880) 
display (218DPI) and on a MacBook Pro 13" with retina display. Same 
result. Here is a screen capture of the iMac [2].

As can be seen, the text is also perfectly rendered. It is as sharp, 
black and crisp.

This confirms that the reported font rendering problem is due to a 
limitation of screen resolution (pixel size).

I would like to know if a more common HiDPI screens (27" 3840x2160 
163DPI) will still give an acceptable result. The price of such type of 
screen start at ~300€ which is far more affordable than a Mac screen. At 
50cm, which is the average distance for a desktop setup, the eye won’t 
be able to distinguish pixels with a 163 DPI screen. I couldn't get a 
hand on such type of screen yet.


[1] https://imgur.com/a/lJNepgz

[2] https://imgur.com/a/Ca78FaF

-- 
Bien cordialement,
Ch.Meessen
Alessandro Arzilli
Details
Message ID
<20210624095412.gm4wgwuhqjmrn24z@x1>
In-Reply-To
<76063d66-8885-e2ac-8a32-98de5314c60a@meessen.net> (view parent)
DKIM signature
pass
Download raw message
How can you say this is perfect? Look how misshapen and thin the 'e' and the
'z' are, specially on the smaller font size. Look how thin is the bottom bar
of the z compared to the top bar.
Also look how light it is compared to text rendered by the system at a much
smaller size.

On Thu, Jun 24, 2021 at 11:34:22AM +0200, Christophe Meessen wrote:
> Hello,
> 
> I could test the component example to evaluate text rendering with GIO of my
> iPhone and iPad, and the rendering is perfect. The iPhone is ~400DPI and the
> iPad is 220 DPI. This is a screen capture from my iPad [1].
> 
> Someone tested the kitchen example on an iMac with 27" (5120x2880) display
> (218DPI) and on a MacBook Pro 13" with retina display. Same result. Here is
> a screen capture of the iMac [2].
> 
> As can be seen, the text is also perfectly rendered. It is as sharp, black
> and crisp.
> 
> This confirms that the reported font rendering problem is due to a
> limitation of screen resolution (pixel size).
> 
> I would like to know if a more common HiDPI screens (27" 3840x2160 163DPI)
> will still give an acceptable result. The price of such type of screen start
> at ~300€ which is far more affordable than a Mac screen. At 50cm, which is
> the average distance for a desktop setup, the eye won’t be able to
> distinguish pixels with a 163 DPI screen. I couldn't get a hand on such type
> of screen yet.
> 
> 
> [1] https://imgur.com/a/lJNepgz
> 
> [2] https://imgur.com/a/Ca78FaF
> 
> -- 
> Bien cordialement,
> Ch.Meessen
> 
Details
Message ID
<CAD+eXGQpm2faOjUeVHDEOnJuW9b65S6xAwrgwRhZUuxMdX04EQ@mail.gmail.com>
In-Reply-To
<20210624095412.gm4wgwuhqjmrn24z@x1> (view parent)
DKIM signature
pass
Download raw message
What Alessandro said.

At 192 DPI text is lighter compared to browser and it's immediately noticeable.

If you're looking for a 4k display I use this one and can recommend it
https://www.tftcentral.co.uk/reviews/acer_nitro_xv273k.htm
Details
Message ID
<beefbddb-13cb-f53f-82e8-c365b842a078@meessen.net>
In-Reply-To
<20210624095412.gm4wgwuhqjmrn24z@x1> (view parent)
DKIM signature
pass
Download raw message
Thank you for pointing this out. There are indeed artifacts with the 
Component example. They are not present with the Kitchen example.

These are short white lines at the bottom of some letters. Is it a white 
dashed line overriding text ?  It is well noticeable on the bottom 
horizontal line of the uppercase B of the labels Contextual App Bar and 
Bottom App Bar.

But note that this problem is different from the effect of a too big 
pixel size (low DPI) which result in gray and fuzzy letters due to 
dominating antialiasing.

It can’t yield the same result than Apple with small font size because 
Apple is most probably doing stem darkening which I understood is 
basically thickening fonts. GIO is doing nothing to adjust small size 
glyph layouts. It is normal that small size text is also subject to 
dominating antialiasing on HiDPI screen too. But how small does the text 
have to be to become a problem ?


Le 24/06/2021 à 11:54, Alessandro Arzilli a écrit :
> How can you say this is perfect? Look how misshapen and thin the 'e' and the
> 'z' are, specially on the smaller font size. Look how thin is the bottom bar
> of the z compared to the top bar.
> Also look how light it is compared to text rendered by the system at a much
> smaller size.
>
> On Thu, Jun 24, 2021 at 11:34:22AM +0200, Christophe Meessen wrote:
>> Hello,
>>
>> I could test the component example to evaluate text rendering with GIO of my
>> iPhone and iPad, and the rendering is perfect. The iPhone is ~400DPI and the
>> iPad is 220 DPI. This is a screen capture from my iPad [1].
>>
>> Someone tested the kitchen example on an iMac with 27" (5120x2880) display
>> (218DPI) and on a MacBook Pro 13" with retina display. Same result. Here is
>> a screen capture of the iMac [2].
>>
>> As can be seen, the text is also perfectly rendered. It is as sharp, black
>> and crisp.
>>
>> This confirms that the reported font rendering problem is due to a
>> limitation of screen resolution (pixel size).
>>
>> I would like to know if a more common HiDPI screens (27" 3840x2160 163DPI)
>> will still give an acceptable result. The price of such type of screen start
>> at ~300€ which is far more affordable than a Mac screen. At 50cm, which is
>> the average distance for a desktop setup, the eye won’t be able to
>> distinguish pixels with a 163 DPI screen. I couldn't get a hand on such type
>> of screen yet.
>>
>>
>> [1] https://imgur.com/a/lJNepgz
>>
>> [2] https://imgur.com/a/Ca78FaF
>>
>> -- 
>> Bien cordialement,
>> Ch.Meessen
>>
-- 
Bien cordialement,
Ch.Meessen
Alessandro Arzilli
Details
Message ID
<20210624114233.yobexy34phkzii4p@x1>
In-Reply-To
<beefbddb-13cb-f53f-82e8-c365b842a078@meessen.net> (view parent)
DKIM signature
pass
Download raw message
This isn't a very scientific discussion. There should be a side-to-side
comparison with text in the same font rendered by the system (or by a
freetype) to get some objectivity going.

As far as I know the artifacts we're seeing could have been introduced by
the notoriously aggressive compression of imgur.

> It can’t yield the same result than Apple with small font size because Apple
> is most probably doing stem darkening which I understood is basically
> thickening fonts. GIO is doing nothing to adjust small size glyph layouts.
> It is normal that small size text is also subject to dominating antialiasing
> on HiDPI screen too. But how small does the text have to be to become a
> problem ?

My understanding is that stem darkening is actually fairly uncommon and
what's most likely is that Apple is simply rendering the font with the gamma
correction it was designed to have. Also note that the small text at the top
is 18px, not actually small at all!

Re: Text rendering on HiDPI screen (more info on artifact)

Details
Message ID
<ab1567b5-eb98-f563-a041-efe895ccf733@meessen.net>
In-Reply-To
<20210624114233.yobexy34phkzii4p@x1> (view parent)
DKIM signature
pass
Download raw message
More information on the artifact.

It is not caused by compression. It is already visible on the iPad 
display, but it is then small.

Here is a screen capture of the artifact obtained with the application 
Gophers [1]. It is also visible with the kitchen example when run on iOS 
[2]. I was impressed how the exact same code could run on my desktop and 
my iPad.

I notice that the editable text rounded rectangle frame is not properly 
rendered in the kitchen app. I do get the exact same result with the 
kitchen rendered with WASM in safari [3]. I could not edit text (to 
slow?) to test the presence of the artifact. Apparently, it is not 
present. The kitchen example rendered with WASM in firefox on Ubuntu is 
rendering the editable text frame as expected [4].

The artifact noticed by Alessandro is only visible on iOS. It is not 
present on the MacOS. I don’t have an android phone or tablet for testing.


Le 24/06/2021 à 13:42, Alessandro Arzilli a écrit :
> This isn't a very scientific discussion. There should be a side-to-side
> comparison with text in the same font rendered by the system (or by a
> freetype) to get some objectivity going.

I agree and wished I could do that. Unfortunately I can’t create text 
with google fonts on my iPad. Do you have a suggestion ?

> My understanding is that stem darkening is actually fairly uncommon and
> what's most likely is that Apple is simply rendering the font with the gamma
> correction it was designed to have. Also note that the small text at the top
> is 18px, not actually small at all!

The top most multi-line editable text in the kitchen example is in 16pt.

Adobe is doing stem darkening since a long time now [5] and provided the 
code to FreeType (open source) in 2013. Auto hinting is apparently able 
to produce the same result. The formula used by Apple for font dilation 
(stem darkening) is provided here [6] by Patrick Walton (PathFinder). 
Thus stem darkening which is emboldening fonts is apparently fairly 
common, but only relevant and needed with small size text.

The gamma adjustment is indeed a working solution (hack) for LoDPI 
screens that I already demonstrated in a previous test shared on this 
mailing list. But Elias said he don’t want to go that way. I agree that 
it would make the GIO implementation more complex because we would need 
a special processing path for text rendering. Currently, text is treated 
like any other shape filling.

The test results I finally managed to collect today proved to me that we 
don’t need any special treatment for font rendering with HiDPI screens 
and normal size text. A kind reader of this mailing list sent me a 
screen capture of the Kitchen example run on a 27" 4k screen. It is 
similar to the one I got with the MacOS and its 5k screen.

I agree that good font rendering on low DPI screens would be nice to 
have, but I don’t see it as a top priority.


[1] https://imgur.com/fZwgjKX

[2] https://imgur.com/v3j8Oha

[3] https://imgur.com/5YCjr31

[4] https://imgur.com/FyLHGrh

[5] 
https://www.freetype.org/freetype2/docs/hinting/text-rendering-general.html#experimental-stem-darkening-for-the-auto-hinter

[6] https://twitter.com/pcwalton/status/918991457532354560


-- 
Bien cordialement,
Ch.Meessen

Re: Text rendering on HiDPI screen (more info on artifact)

Details
Message ID
<CCC392OUQDW0.25OLF4U449DEM@testmac>
In-Reply-To
<ab1567b5-eb98-f563-a041-efe895ccf733@meessen.net> (view parent)
DKIM signature
pass
Download raw message
On Thu Jun 24, 2021 at 18:09 CEST, Christophe Meessen wrote:
> The gamma adjustment is indeed a working solution (hack) for LoDPI 
> screens that I already demonstrated in a previous test shared on this 
> mailing list. But Elias said he don’t want to go that way. I agree that 
> it would make the GIO implementation more complex because we would need 
> a special processing path for text rendering. Currently, text is treated 
> like any other shape filling.
>

I suppose it would be ok if we could figure out a way to draw only the
antialiased text edges with a lower gamma value. The compute renderer
does gamma correction internally and doesn't rely on builtin GPU
hardware, so it's not a far off idea.

Elias

Re: Text rendering on HiDPI screen (more info on artifact)

Christophe Meessen
Details
Message ID
<01293fdb-6763-6233-8171-16dbc6229708@cppm.in2p3.fr>
In-Reply-To
<CCC392OUQDW0.25OLF4U449DEM@testmac> (view parent)
DKIM signature
missing
Download raw message
Hello,


Le 24/06/2021 à 21:17, Elias Naur a écrit :
> On Thu Jun 24, 2021 at 18:09 CEST, Christophe Meessen wrote:
>> The gamma adjustment is indeed a working solution (hack) for LoDPI
>> screens that I already demonstrated in a previous test shared on this
>> mailing list. But Elias said he don’t want to go that way. I agree that
>> it would make the GIO implementation more complex because we would need
>> a special processing path for text rendering. Currently, text is treated
>> like any other shape filling.
>>
> I suppose it would be ok if we could figure out a way to draw only the
> antialiased text edges with a lower gamma value. The compute renderer
> does gamma correction internally and doesn't rely on builtin GPU
> hardware, so it's not a far off idea.
>
When the text is black on white background, darkening the gray pixels 
due to anti-aliasing has a similar effect to emboldening fonts. It’s not 
exactly the same though.

Nigel Tao rasterize font into a mask that can then be composed with 
color pixels. In this case adjusting the grayness of pixels of the mask 
could indeed be the solution.

I don’t know if compute use a mask. Unfortunately, I’m a complete noob 
in opengl and can’t help you.

I can do some demonstrations of gamma correction on text to see how well 
it could fix the issue.


-- 
Bien cordialement,
Ch.Meessen

Re: Text rendering on HiDPI screen (more info on artifact)

Details
Message ID
<a53b5eb5-8ebc-b835-5588-3553879c34f0@meessen.net>
In-Reply-To
<01293fdb-6763-6233-8171-16dbc6229708@cppm.in2p3.fr> (view parent)
DKIM signature
pass
Download raw message
Hello

I did further tests with a side by side comparison of Go regular text 
rendered by x/image/text and GIO’s kitchen example. Here is the result [1].

There is a scaling difference with a ratio of 92/72 measured with the 
text length. The cause is not obvious. The size of a pt is 1/72th inch. 
If the screen DPI was 72, 1 pt would be a pixel. With a 92DPI screen, 
1pt is 92/72 pixels. I would thus tend to think that the bigger text is 
properly scaled, but it’s not rendering as well. I will investigate this.

Here is another test I did. It’s a comparison of the effect of different 
gamma values on go regular [2] and go italic [3] size 12pt. As can be 
seen, the effect is minor but perceptible and slightly reduce the 
grayness and fuzziness of text.


[1] https://imgur.com/fCdX3o7

[2] https://imgur.com/TEAHW1L

[3] https://imgur.com/TpOJXVA


Le 28/06/2021 à 10:38, Christophe Meessen a écrit :
> Hello,
>
>
> Le 24/06/2021 à 21:17, Elias Naur a écrit :
>> On Thu Jun 24, 2021 at 18:09 CEST, Christophe Meessen wrote:
>>> The gamma adjustment is indeed a working solution (hack) for LoDPI
>>> screens that I already demonstrated in a previous test shared on this
>>> mailing list. But Elias said he don’t want to go that way. I agree that
>>> it would make the GIO implementation more complex because we would need
>>> a special processing path for text rendering. Currently, text is 
>>> treated
>>> like any other shape filling.
>>>
>> I suppose it would be ok if we could figure out a way to draw only the
>> antialiased text edges with a lower gamma value. The compute renderer
>> does gamma correction internally and doesn't rely on builtin GPU
>> hardware, so it's not a far off idea.
>>
> When the text is black on white background, darkening the gray pixels 
> due to anti-aliasing has a similar effect to emboldening fonts. It’s 
> not exactly the same though.
>
> Nigel Tao rasterize font into a mask that can then be composed with 
> color pixels. In this case adjusting the grayness of pixels of the 
> mask could indeed be the solution.
>
> I don’t know if compute use a mask. Unfortunately, I’m a complete noob 
> in opengl and can’t help you.
>
> I can do some demonstrations of gamma correction on text to see how 
> well it could fix the issue.
>
>
-- 
Bien cordialement,
Ch.Meessen
Reply to thread Export thread (mbox)