Randomly corrupt font / text / characters in Unity8

[Daniel van Vugt]

Corrupted characters in text rendering.

Only happens after starting non-GL application, like GTK application or mir_demo_client_fingerpaint.

[Lukáš Tinkl (lukas-kde)]

Can you attach a screenshot please? Thanks

[kevin gunn (kgunn72)]

comparison screenshot even better

[Daniel van Vugt (vanvugt)]

Here's a screenshot of a couple of slightly corrupt titlebars.

Ignore the messed up window contents. That's just a screenshot bug I'll log separately. The window contents look right on the real screen. But the corrupt titlebar text is visible.

[Daniel van Vugt (vanvugt)]

Other bugs are visible in that screenshot:
  Blurry window contents after moving (Web Browser) -> bug 1510382
  White/translucent window contents for screenshots of Xmir -> bug 1583399
  All white QML window contents for Scopes -> bug 1577639
  Thin titlebar font -> bug 1583092

Sorry for the confusion. I didn't intend to capture so may bugs in one picture.

[Daniel van Vugt (vanvugt)]

Oh bug 1543467 is visible too.

[Gerry Boland (gerboland)]

This is on Intel I guess? Your investigations into bug 1580792 does point out that the driver complains of a bad argument to glCopyTexSubImage - the only consumer of glCopyTexSubImage that I can find is in the Qt's font rendering system - so if it fails, it would cause font rendering issues. That's my best guess currently

[Daniel van Vugt (vanvugt)]

glCopyTexSubImage isn't failing (it reports no errors), just falling back to slower software rasterization. So that should be visually correct, just slower. It should be unrelated to this bug.

[Daniel van Vugt (vanvugt)]

It's only certain characters that are sometimes corrupt. So it's the typography renderer at fault and not the shell.

Here's a pair of screenshots showing the glyph '4' is corrupt for me today, and what it looks like when the clock changes from '11:43' to '11:44'.

[Daniel van Vugt (vanvugt)]

And a completely different screenshot of the same bug. Here it's kind of more obvious that the glyph renderer is using an incorrect buffer stride/width.

[Marlin Forbes (datashaman)]

I'm seeing the same corruption in Gnome Shell in Ubuntu Xenial, it's not Unity-specific. I'm using the intel graphics driver from ppa:oibaf/graphics-drivers (to try and upgrade myself out of the issue), but it was happening before changing to a custom PPA.

[Launchpad Janitor (janitor)]

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

[Gerry Boland (gerboland)]

If you can reproduce this relative easily, could you try setting QML_USE_GLYPHCACHE_WORKAROUND=1 for unity8. This should do the trick:

stop unity8 && start unity8 QML_USE_GLYPHCACHE_WORKAROUND=1

Can also try these:
QSG_DISTANCEFIELD_ANTIALIASING=subpixel-lowq or gray

Need to determine if that text is being drawn by the DistanceField approach, or using the "native" rendering technique
http://doc.qt.io/qt-5/qml-qtquick-text.html#renderType-prop

If distance field, perhaps the contents of the distance field texture is corrupted somehow. Grabbing the contents of the texture to visually verify it is corrupt or not would be my next step. apitrace might be able to grab the texture. Else would need to write code..

[kevin gunn (kgunn72)]

so question was asked from a previous dupe bug about repro steps. afaict, there are no specific repro steps and the specific letters which get corrupted seems random. But I've been using unity8 quite regularly, and I've seen this several times so doesn't seem infrequent.

Might be worth noting that once a letter gets corrupt it seems corrupted everywhere for that rendering - for instance on the power down prompt, the letter "f" is repeated in the word "off" in 2 different places - in one experience, no other letters were corrupted expect "f" in all 4 locations.

[Gerry Boland (gerboland)]

That would imply the distance field texture is corrupted.

As a note to myself, there is a nice glyph test application in this bug:
https://bugreports.qt.io/browse/QTBUG-49490

[Gerry Boland (gerboland)]

Also worth noting, there are env vars:
QT_DEFAULT_TEXTURE_GLYPH_CACHE_WIDTH & HEIGHT to set the size of the glyph cache. Need to see what size texture Qt is creating, perhaps it is creating one too large for the hardware </guess>

[draco (draco31-fr)]

Screenshot on comment 12 seems very close to behaviour in bug #1573959 , which is present only on Intel graphic cards. Could it be the same bug ?

[Daniel van Vugt (vanvugt)]

Comments #11 and #12 are not this bug at all. I have hidden those now to avoid confusion.

[Daniel van Vugt (vanvugt)]

This is still happening in zesty (seen today in the Unity8 indicator menu and logout dialog).

It looks like the text renderer might have mistaken buffer width for buffer stride in some cases...?

[dinamic (dinamic6661)]

same here on both 17.04 and 16.04+overlay (intel and nvidia)

[Daniel van Vugt (vanvugt)]

Just updating the bug title so that people searching for keywords can find it (Launchpad only finds keywords separated by spaces)

[dinamic (dinamic6661)]

just my observation, i only see character corruption when using Xmir (on desktop), i am now using unity8 for 20h and the fonts look ok, no corruption.

[dinamic (dinamic6661)]

hm.. ok.. so not sure it's Xmir, now i gedit corrupted my fonts, after 20h of using only ubuntu system apps and qt5 apps i just run "ubuntu-app-launch gedit" and my fonts are corrupted now, i have to restart :D

[Daniel van Vugt (vanvugt)]

It's not Xmir. I experience this bug with the default Unity8 setup (just settings and web browser apps).

[Daniel van Vugt (vanvugt)]

Without knowing what project is to blame or where the source code is, I think this actually looks like a glPixelStorei bug, or lack of glPixelStorei. If you don't call glPixelStorei before your glTexImage2D then the default unpack alignment is 4 bytes. And it's possible the font glyph cache code doesn't know that, assuming default stride alignment is to 1 byte accuracy instead.

[kevin gunn (kgunn72)]

@Gerry
I was going to try your suggestion, stop unity8 && start unity8 QML_USE_GLYPHCACHE_WORKAROUND=1. but it seems simply starting and stopping unity8 is unhappy on zesty atm

fwiw, my current setup I'm seeing this 100%, and i agree cache seems likely as first few windows are ok, but eventually text gets corrupt

[Gerry Boland (gerboland)]

@kgunn - yes I can reproduce it quite reliably too. No need to try the glyph cache workaround thing, I checked it and it had no impact.

@duflu - Qt is rendering the text.

Since Qt renders text ok in Unity7, there must be some GL configuration problem in QtMir/QtUbuntu causing this kind of issue. At the moment, I've not really dug into why.

[Daniel van Vugt (vanvugt)]

It could still be lack of glPixelStorei. In many cases the default unpack alignment will be right by accident, so in those cases the text will appear correct. It's possible that a different backend (X11 vs Mir) creates a slightly different GL state and so the bug only appears in some backends but not others.

[Daniel van Vugt (vanvugt)]

I'm referring to the diagonal lines problem, like we see here and like is documented here:
https://www.khronos.org/opengl/wiki/Common_Mistakes#Texture_upload_and_pixel_reads

[Gerry Boland (gerboland)]

I'm looking into this now. I took an api trace of some simple font rendering by Qt on Mir showing the problem, and executed it on my X11 session. It renders ok on X11. Reading through the apitrace, Qt seems to be doing the right thing.

I suspect the mismatch we have between Mir creating a GLES context and Qt expecting a GL context is hitting us here.

[Daniel van Vugt (vanvugt)]

If you could point me to the exact code that does the glyph rendering/caching I would be interested to read it...

[Gerry Boland (gerboland)]

@vanvugt
you were right that glPixelStorei was to blame. In ShmBuffer Mir uses glPixelStorei to change the GL_UNPACK_ALIGNMENT from 4 (that Qt set) to 1 (that Mir sets, as it is more careful about stride).

Mir fails to restore the state the Qt set, which broke Qt's rendering from then on.

ShmBuffer only used for clients that do not use GL to draw, so Gtk and mir demos like fingerpaint, which is why this bug was "random"

Could Mir be patched to revert any GL state changes it makes, when called into by Qt?

[Daniel van Vugt (vanvugt)]

Yes, but probably no :)

Performance of the GL pipeline suffers, sometimes dramatically, if you glGet-anything like the current GL_UNPACK_ALIGNMENT.

So getting it for later restoration is highly undesirable. Better to just set it to the right value whenever it's important. That keeps communication between the CPU and GPU in one direction and avoids stalling the pipeline.

https://www.khronos.org/opengl/wiki/Common_Mistakes#glGetFloatv_glGetBooleanv_glGetDoublev_glGetIntegerv

[dinamic (dinamic6661)]

using silo 2481, seems to work fine, i don't see the font corruption anymore

[Daniel van Vugt (vanvugt)]

Awesome.

I would like to see a permanent fix done in a more appropriate place though. I think somewhere in qtdeclarative-opensource-src there is the bad assumption about the current state of GL_UNPACK_ALIGNMENT. We need to find that code and add an explicit setting right before it uploads the corrupt/skewed texture.

[Gerry Boland (gerboland)]

Here is what Qt is doing, on upload:
https://code.woboq.org/qt5/qtdeclarative/src/quick/scenegraph/qsgdefaultdistancefieldglyphcache.cpp.html#158
It saves & restores the alignment, and assumes the default alignment of 4 for drawing. IMO Mir isn't playing along, as it changes the alignment but does not restore it.

[Daniel van Vugt (vanvugt)]

Assuming the current value is 4 might be incorrect in this case but also won't cause the bug unless they also fail to call "glPixelStorei(GL_UNPACK_ALIGNMENT, 4)" somewhere that they need it to be 4.

Where you see Qt code that uses alignment 1, that's not relevant here because it will play perfectly with Mir. The problem is elsewhere... some GL unpacking without a glPixelStorei call is being done and that location expects/requires alignment of 4.

So I guess start by searching for all glTexImage2D calls and ensure they are all /immediately/ preceded by glPixelStorei. It's possible Qt already has some housekeeping for that but then the bind call happens in the middle:

Qt: glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
Qt: calls the offending Mir bind code
Qt: glTexSubImage2D or glTexImage2D

So the fix then would still be in qtdeclarative; either reorder lines 1 & 2, or add another glPixelStorei call in before the glTex*Image2D calls in Qt.

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package qtmir - 0.5.1+17.04.20170307-0ubuntu1

---------------
qtmir (0.5.1+17.04.20170307-0ubuntu1) zesty; urgency=medium

  [ Albert Astals Cid ]
  * Fix clang build

  [ Daniel d'Andrada ]
  * Some qtmir::Session fixes
  * Make TaskController absorb SessionManager
  * Don't pass command line arguments to Mir
  * Reduce default log verbosity (LP: #1664151)
  * DBusFocusInfo: fix crash when trying to access a null session from
    an application (LP: #1670710)

  [ Gerry Boland ]
  * Workaround for Mir changing GL state unexpectedly on Qt, breaking
    font rendering. (LP: #1583088)

  [ Lukáš Tinkl ]
  * Use the shell chrome, as provided by miral window info (LP:
    #1658117)

 -- Lukáš Tinkl <email address hidden> Tue, 07 Mar 2017 23:43:16 +0000