Font/text rendering is irregular and not pixel-aligned on low DPI screens

[Andrea Bernabei]

This is a Dell Vostro 3550 laptop with a fresh install of 16.04 and unity8 Mir session

the version of qtdeclarative5-qtmir-plugin is 0.4.7+16.04.20160104-0ubuntu1

As you can see from the screenshots the text has low details and, in the case of indicators descriptions at the top, almost disappears.

The text could be fixed by using Text.NativeRendering instead of Text.QtRendering for the QML labels on low dpi screens, although text doesn't seem to be the only issue here. The icons are definitely lacking detail as well (QML Image's smoothing is enabled maybe?).
Also the dots of the infographic don't look like circles at all, they're missing pixels and many of them look like a C more than an O.

It looks to me like something is setting the wrong resolution, because it looks quite bad. But the screenshots are 1366x768 so I think that's not the case.

NOTE: Unity7 looks perfectly fine and detailed

[Andrea Bernabei (faenil)]

I posted a few screenshots above to show how bad the situation is :D
They compare all the text rendering related antialiasing settings that Qt offers with the native text rendering algorithm (on the right in all screenshots)

The fontSize of the strings are the ones provided by the current Ubuntu UI Toolkit

Unity8 version is 8.11+16.04.20160122-0ubuntu1
The laptop is running the latest Xenial packages as of today 26th Jan 2016

The hardware is Dell Vostro 3550 (1366x768 screen)

Antialiasing is probably too much for low-dpi screens, and it ends up almost deleting letters while trying to smooth them out.

[Gerry Boland (gerboland)]

Reassigning to Unity8. Will probably need work in UITK too

[Gerry Boland (gerboland)]

My understanding is that Qt's distance field approach to font rendering does not do grid-fitting of characters. So for small font sizes on low-dpi screens, font characters can be poorly antialiased, with 1-pixel wide aspects of the character being rendered between pixels.

Distance field text is far better suited to small text which animates - moves position on screen, scales up/down, etc.

Qt lets us choose an alternative option, using native font rendering, which does perform grid-fitting of characters, and looks superior as Andrea has shown in his analysis. We can enable this with the "renderType" property like so:

Text {
    text: "Some text"
    renderType: Text.NativeRendering
}

To solve, need to carefully assess each Text/Label instances in shell & apps, and decide which to use.

UITK might decide to switch to native rendering for font sizes below a certain threshold.

[Andrea Bernabei (faenil)]

Florian already has an MR ready that changes UI Toolkit Label to use NativeRendering automatically when the pixels per GU in a device is <=10 (Unless the developer overrides the property, that is)

https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/native_rendering_at_low_dpi/+merge/282808

We just need to pull the trigger, if we want to go on with it

[Gerry Boland (gerboland)]

Works for me

[Florian Boucault (fboucault)]

Let's be clear though, the issue seen on xenial and qt5.5 is _not_ reproduced on 15.10. There is a real regression in text rendering on xenial that the MR is not meant to fix.

[Andrea Bernabei (faenil)]

That's a very good point. The issue is not nearly as bad on Vivid+PPA (my laptop), but there are so many differences with Xenial that it's hard to point out the faulty package (although it could be Qt).

This needs more investigation, but I can't spend more time on this now...

[Andrea Bernabei (faenil)]

Update:
the app running in Unity7 screenshots is running from QtCreator using the "Desktop Kit" which is provided by Ubuntu SDK IDE.

That means, it's using Qt5.4.2 (doublechecked using lsof -p <pid>, gotta love that command!)

For that reason, I think the problem we have in Xenial is not coming from the new Qt version, it has to be something else!

[Timo Jyrinki (timo-jyrinki)]

The possible suspects below, from qtbase build dependencies.

package | vivid | xenial
fontconfig | 2.11.1-0ubuntu6 | 2.11.1-0ubuntu6
freetype | 2.5.2-2ubuntu3.1 | 2.5.2-4ubuntu2
harfbuzz | 0.9.37-1 | 1.0.1-1build2

harfbuzz could be the most likely suspect. However, also wily has 1.0.1-1build2 - could you test the issue on wily? If it's broken there too, I could try to help by forward-porting old harfbuzz to xenial. But if it's not broken there, then it's probably not harfbuzz and also not freetype or fontconfig (same versions in wily and xenial of all them).

[Timo Jyrinki (timo-jyrinki)]

Florian mentioned ubuntu font too, that's a good candidate too and should be pretty easy to grab the vivid's Ubuntu font files and put on xenial. Just wget https://launchpad.net/ubuntu/+source/ubuntu-font-family-sources/0.80-0ubuntu6/+build/4932536/+files/ttf-ubuntu-font-family_0.80-0ubuntu6_all.deb and installing should work.

[Florian Boucault (fboucault)]

I believe that Qt is selecting the newly introduced Ubuntu Thin instead of Ubuntu Light.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

The problem is seemingly reduced in xenial now with the new visual design. But the problem is not eliminated.

Fonts in the indicator pulldown (on desktop) are still not very well pixel aligned. At a guess, it looks like we might have made any of these mistakes:
   (a) Insufficient hinting
   (b) Text is pre-rendered in a bitmap whose background colour is different to the final screen.
   (c) Text rendering is trying to use sub-pixel alignment, but only getting greyscale on screen (see (b))

Sad to say Unity7 text still looks much nicer.

[Daniel van Vugt (vanvugt)]

Seems to be totally fixed in xenial today!

Can anyone confirm what package fixed it?

[Daniel van Vugt (vanvugt)]

Reopened again. Although the situation definitely got better at the start of April, font rendering in Unity8 still looks quite poor when compared to Unity7.

The problem might just be misaligned textures like Unity8 bug 1510382.

[Timo Jyrinki (timo-jyrinki)]

I can't think of anything relevant changed in Qt itself since 5.5.1 landed in xenial in December, so it must have been some other package.

You may want to test Qt 5.6.0 to see if that gives any further improvement https://wiki.ubuntu.com/Touch/QtTesting

The current plan would be to have Qt 5.6(.1) in xenial-overlay eventually.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

It just occurred to me, the visual quality of text rendering would improve a lot with sub-pixel rendering vs the greyscale rendering we see. So Mir needs to expose sub-pixel ordering information before we can do that --> bug 1393578

[Andrea Bernabei (faenil)]

Hi Daniel,

have you had a look at the screenshots I attached, showing the results of the distance field QML Text rendering comparing gray vs subpixel-lowq vs subpixel-highq antialiasing modes?

(although I guess you're talking about native text rendering, but I still thought it'd be worth pointing that out in case you missed them :) )

[Daniel van Vugt (vanvugt)]

Yeah thanks. Sub-pixel appears to partially work, although I suspect we have the RGB/BGR ordering backwards. And that's not surprising because of bug 1393578. Unity8 has no way of knowing the correct sub-pixel ordering while Mir doesn't provide it.

[Daniel van Vugt (vanvugt)]

Just noticed this bug again, now in System Settings. On Unity7 it's perfectly clear (sub-pixel RGB) but in Unity8 it's slightly blurry (greyscale is used). So that's the first part of the problem.

The second part of the problem is that Unity8 (especially in the indicator pulldown) failing to apply a nice hinting setting to make the glyph curves aligned to pixel boundaries more often. So a glyph that should be represented as one pixel thickness is rendered as two half pixels in greyscale, which is ugly.

[Andrea Bernabei (faenil)]

@Daniel:

I think font hinting is disabled by default for QML Text elements, because Text uses distance fields rendering by default (more info at http://blog.qt.io/blog/2011/07/15/text-rendering-in-the-qml-scene-graph/ )

That was changed in the Label component of our UI toolkit so that it uses "NativeRendering" when the Grid Unit is <= 10, distance fields otherwise. See comment #19.

So that could potentially be fixed by using Label instead of the standard QML Text in indicators/dash/etc

[Daniel d'Andrada (dandrader)]

On 13/07/2016 06:45, Daniel van Vugt wrote:
> The second part of the problem is that Unity8 (especially in the
> indicator pulldown) failing to apply a nice hinting setting to make the
> glyph curves aligned to pixel boundaries more often. So a glyph that
> should be represented as one pixel thickness is rendered as two half
> pixels in greyscale, which is ugly.
>
About the indicators: do you see blurry text only *while* you're
dragging it down or do you see it also afterwards, when its fully extended?

[Daniel van Vugt (vanvugt)]

When it's fully extended the fonts look bad. So this is not a texture coordinate problem. I think the surface texture is correctly pixel aligned but we haven't yet made sure the font hinting within the surface is also pixel-aligned. Unity7 text still looks nicer and more polished than Unity8.

[Andrea Bernabei (faenil)]

I'm still curious to know if anyone checked if there's any font hinting at all, in those labels :)

[Daniel van Vugt (vanvugt)]

Found this image today, showing Unity8's font rendering next to GTK's:
https://launchpadlibrarian.net/290523497/IMG_1258.JPG

[Daniel van Vugt (vanvugt)]

Technically not really a High bug, but we should keep a close eye on the number of visual regressions in Unity8 compared to Unity7. So that overall problem is itself High.

[Daniel van Vugt (vanvugt)]

I can now see part of the problem more clearly.

If you look at labels that contain the same letter multiple times like "Calculator" or "Security & Privacy", then it becomes apparent that the clarity of that same letter changes depending on where it is in the word.

Given that Qt caches individual glyphs (discovered in bug 1583088), this variation in clarity should never happen. Most likely the problem is Qt's text rendering is failing to place some glyphs at integer x locations, which is a big deal on regular low DPI displays.

[Daniel van Vugt (vanvugt)]

Also the two lower-case u's in "Ubuntu App Test" have particularly different appearance.

It seems Qt is placing glyphs according to a higher fractional precision than the resolution of the display, which while technically correct also creates unacceptable blurring of text at low DPI.

[Daniel van Vugt (vanvugt)]

It might be acceptable if the hinting was higher quality, but I think that would require caching of whole strings (possibly with kerning) rather than caching of individual glyphs.

[Michał Sawicz (saviq)]

A related QTBUG for Windows is [1] - and the last comment [2] suggests what should be done here.

Our UITK's Label element, being mostly non-transformed, should probably use Text.NativeRendering [3] (maybe depending on DPI?) and document clearly that if you want transformable / animated text, you either want to use QtQuick's Text, or use Text.QtRendering renderType [3].

[1] https://bugreports.qt.io/browse/QTBUG-28993
[2] https://bugreports.qt.io/browse/QTBUG-28993?focusedCommentId=194208&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-194208
[3] https://doc.qt.io/qt-5/qml-qtquick-text.html#renderType-prop

[Gerry Boland (gerboland)]

UITK already using NativeRendering for text when GU<10.

Text *might* be improved by setting Qt's DPI and sub-pixel rendering hints correctly.

[Daniel van Vugt (vanvugt)]

Yeah I noticed QML_DISABLE_DISTANCEFIELD=1 made no improvement.

[Andrea Bernabei (faenil)]

see the first comments for a few (old) experiments I made using different Qt font antialiasing settings

[Mattia Rizzolo (mapreri)]

Is this issue still present after some years? I don't have any low-DPI system at hand (I really only have hi-DPI screens… :P)

[Daniel van Vugt (vanvugt)]

We don't support Unity8 now and have no way to verify or test it.