[Worked around] N900 QtQuick2 Text rendering bug
-
Hello,
I'm trying to port "Qt5 for the N900":https://qt.gitorious.org/+qt5-maemo5/qt/qt5-maemo5-qtdeclarative and it worked quite well (despite some hacking with old xcb versions). However there is a nasty bug concerning Text elements in QtQuick2. Whenever the text is changed (e.g. after a click in the mousearea example) the text gets totally corrupted. The bug is likely connected to OpenGL ES and Scenegraph. Therefore I ran the example with PVRTrace. "This file":http://repos.fuhlbrueck.net/qt5-maemo5-examples/frm.txt contains the functions between two consecutive frames and the content of the framebuffer can be seen in the images below.
The N900 contains an OMAP3430 (with SGX530 graphics). I've already tried the workarounds available via switch in the sources and all possible tricks from http://gitorious.org/qt-platform-mkspecs/qt-platform-mkspecs/blobs/master/5.0/linux-omap3430-g++/qmake.conf.
"Maemo.org Thread":http://talk.maemo.org/showthread.php?t=84782
"Maemo.org wiki page":http://wiki.maemo.org/Qt5-Maemo5-DevelopmentAny help is greatly appreciated.
Before the text is changed (via "Click"):
!http://repos.fuhlbrueck.net/qt5-maemo5-examples/sc1.png(image before text change)!After the text is changed:
!http://repos.fuhlbrueck.net/qt5-maemo5-examples/sc2.png(image before text change)! -
FYI, I don't know if it's related but I have similar issue when debugging a Qt5 app on Windows XP if I stay too long in a breakpoint... I hope you success in your port.
-
By "stay long" you mean plain time or does it depend on whether you test certain things? Where do you set those breakpoints (e.g. inside a self written QML component)?
-
Usually it's when I have my breakpoints in the updatePaintNode method. I haven't checked exactly the time condition but text is not always corrupted.
-
Could you provide some (small) publicly accessible example of an updatePaintNode function where this happens?
-
I can't for the moment but I will try to reproduce in a small example as soon as I find some time.
-
This bug might be connected to some glyph cache. While trying an example text editor with an English text all letters got corrupted until I typed an "ä" (German a with umlaut) which did not occur in the text. After some letters the "ä" also got corrupted, but "ö" (then unused) displayed normally.
-I also stumbled upon a stackexchange question (http://stackoverflow.com/questions/2349069/problem-with-freetype-and-opengl) with a similar error which uses freetype and opengl. Could it be that Qt miscalculates some parameters of certain letters because of and old system libfreetype (2.3.9 on N900)? I'll try a rebuild without freetype, but as it works on other platforms, it should work on N900 with a proper freetype too.-
Disabling freetype, using bundled freetype and even disbling fontconfig didn't help. -
The culprit seems to be the glyph cache manager for the distance field node.
https://qt.gitorious.org/+qt5-maemo5/qt/qt5-maemo5-qtdeclarative/commit/716390ccb5c721f11a3e686375a1c9982de97b95 (last file) works around this. Should I file a bug against upstream Qt5? -
Hi,
Nice to hear you found the source of the problem. I think you can file a bug for this as the issue seems to be present on different platforms. At least someone who knows the glyph cache manager part can have a look and maybe fix this issue for the affected platforms.