SUMMARY Launch Krita, and open the first file after launch (tested with .kra and .png files), and the canvas will not show up until you rotate the Android device's screen orientation. If you close all the open files, and then open another file again, the behavior will return to normal, with the canvas appearing without the need to change screen orientation. The bug will happen again if you quit Krita, launch Krita again, and open a file, so this is an issue that only happens with the first open file after launch. This occurs in the 5.3 nightly. This issue does not happen in Krita 5.2.2. STEPS TO REPRODUCE 1. See above. 2. 3. OBSERVED RESULT See above. EXPECTED RESULT Krita should show the canvas right away without needing to change the screen orientation. SOFTWARE/OS VERSIONS Android 13 Krita 5.3.0-prealpha (git 7fb0cda) (2024, June 14) arm64 APK
I can confirm this on 5.2.3, the window requires a manual update trigger (rotating the screen, minimizing the app, etc. Opening a menu triggers a partial update).
*** Bug 489518 has been marked as a duplicate of this bug. ***
Hi, Freya! Do you know, is it possible to reproduce this issue in an emulator? Or it is real hardware only?
Yes, it's possible to reproduce in the Android emulator, but I see a different behavior than on my physical device, I don't know why. On my virtual arm64 device, the window will fail to update, but the floating message about the zoom level will appear, at first partially (on show()) and then fully (on hide()) updating the window. If the floating messages are disabled in Settings->General->Window, then the window will remain un-updated. On my physical arm32 device, the floating message about the zoom level doesn't appear when opening an image, and the window remains un-updated.
*** Bug 490505 has been marked as a duplicate of this bug. ***
On the 5.3 branch this bug is now avoided with the reintroduction of a QML-using docker (the Text Properties docker instead of the Touch Docker). The issue is still present on the 5.2 branch.
*** Bug 491912 has been marked as a duplicate of this bug. ***
Git commit e959198d9a2c10722db0df799e41e71b9c73650e by Halla Rempt. Committed on 03/09/2024 at 12:47. Pushed by rempt into branch 'krita/5.2'. Re-add the throttle docker to 5.2 It's not very useful, but it uses QML, which apparently is enough to make the initialization of the canvas work on Android... M +3 -0 plugins/dockers/CMakeLists.txt A +17 -0 plugins/dockers/throttle/CMakeLists.txt A +77 -0 plugins/dockers/throttle/Throttle.cpp [License: LGPL] A +58 -0 plugins/dockers/throttle/Throttle.h [License: LGPL] A +83 -0 plugins/dockers/throttle/ThrottlePlugin.cpp [License: LGPL] A +35 -0 plugins/dockers/throttle/ThrottlePlugin.h [License: LGPL] A +9 -0 plugins/dockers/throttle/krita_throttle.json A +64 -0 plugins/dockers/throttle/qml/slider.qml * A +5 -0 plugins/dockers/throttle/throttle.qrc The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://invent.kde.org/graphics/krita/-/commit/e959198d9a2c10722db0df799e41e71b9c73650e
Thank you, Halla! :)
Sorry, but that was broken :-(
Now this bug has been fixed in the 5.3 branch. However, it still happens in 5.2.5. Do we need to backport the fix?
Well, my fix wasn't what fixed the bug; I had to revert that. The reason it's fixed in 5.3 is because the text tool adds a new qml-based component. Having one is what fixes the issue, for whatever weird Qt-internal reason.
*** Bug 497103 has been marked as a duplicate of this bug. ***
*** Bug 509748 has been marked as a duplicate of this bug. ***
Git commit fa6e2c76a543ad9e5f69e53403e9acabfbb61127 by Carsten Hartenfels. Committed on 22/09/2025 at 21:40. Pushed by dkazakov into branch 'krita/5.2'. [android] Fix main window not showing document On some Android devices, the main window will sometimes fail to repaint after a document has loaded. The user can interact with the invisible contents of the window, but it won't actually show them properly until Krita is sent to the background once or the user fiddles with the main menu bar. Any attempts to call repaint or update don't work, but hiding and showing the window on subsequent event loop iterations does, so that's what this commit does. A QML docker existing also happens to fix this somehow, so 5.3 with its text properties docker doesn't need this. M +14 -0 libs/ui/KisMainWindow.cpp https://invent.kde.org/graphics/krita/-/commit/fa6e2c76a543ad9e5f69e53403e9acabfbb61127
Thank you, guys! :)