Framstag
Rendering issue with qt6 backend
Link to the rendering issue with qt6 backend: https://github.com/janbar/osmin/issues/107
@Karry , please have you an opinion about the proposed fix of the issuer ?
Hi @janbar . Interesting issue. I saw various rendering issues with SailfishOS using Qt5 and Lipstick renderer (Wailand). But not such artifacts in linked issue. Possibly caused by bug in Qt6. Hard to say.
Anyway, these two lines in MapWidget.cpp was written nine year ago:
setRenderTarget(RenderTarget::FramebufferObject);
setPerformanceHints(PerformanceHint::FastFBOResizing);
when my knowledge of Qt rendering was even more limited than now :-) MapWidget assemble the scene from map tiles or plain map canvas (QImage) and then few primitives, like icon animations, marks... By my knowledge render target controls how these primitives are painted before send to graphic card... As the Qt is using OpenGL backend on most of the systems, using QImage is the best choice. So, remove these two lines and use defaults makes perfectly sense...
But I have no idea if it fix the issue as I cannot reproduce it. @WhiteWind you compiled and tested the Osmin with QImage render target?
Testing the two configurations, current one (FramebufferObject target) feels a bit smoother during map scrolling. Reading the documentation again, I am not sure if it is good idea to switch to QImage target...
FramebufferObject:
As of Qt 6.9, this value will enable hardware-accelerated painting
as long as the rendering API used is OpenGL, otherwise it will
be ignored. For versions Qt 6.0 to Qt 6.8, it will be ignored
on all rendering APIs. This will usually give better rendering
performance, but at the expense of antialiasing quality.
https://doc.qt.io/qt-6/qquickpainteditem.html#RenderTarget-enum and similar formulation in Qt5 docs: https://doc.qt.io/archives/qt-5.15/qquickpainteditem.html#PerformanceHint-enum
AFAIK you can either render directly into the graphics cards (using OpenGL or similar) or you can render into a graphics card buffer via software, or you can render into non-graphics card memory and after that copy the bitmap over to the graphics cards.
Each approach has plus and minus. Graphics cards should be faster but may have, software rendering may have superior quality.
Problems with hardware rendering could be caused by bad drivers, bad access (Qt side) or by reaching constraints regarding memory, object count, missing features in implementation nevertheless used etc...
It could be interesting if problems arise depending on the complexity of the scene. I would suggest supporting both use cases in the code but make them switchable, so that the user can fall back to software rendering if bugs appear.
@WhiteWind you compiled and tested the Osmin with QImage render target?
Yes, tested with QImage and QOpenGLFramebufferObject targets. First shows no graphic corruption, second - shows corruption after entering any letter using Emoji&Font keyboard from Xiaomi or Microsoft Swiftkey keyboard.
Other keyboards do not trigger this bug (GBoard, Hacker's Keyboard, Keepass2Android, MessagEase keyboard)
I guess it is a BUG in the linked Qt framework (6.9.1). I propose to wait next releases for it:
6.9.2 14.08.2025 6.9.3 25.09.2025
And see what happens ...
Qt6 is "young", but I moved to it because the farmer Qt 5.15 doesn't support features of new devices.