488606 2024-06-17 01:01:49 +0000 After Krita launches and you first open a file, the canvas will not show up until you rotate the screen orientation 2026-01-03 23:06:59 +0000 1 1 2 Applications krita Usability nightly build (please specify the git hash!) Android Android 13.x RESOLVED FIXED regression NOR normal --- 1 xeses16388 krita-bugs-null dimula73 dra.w.p.il.e+bugskde edwardmowah fpmangaka halla mixalhs006 osteotripleshield2 penguinflyer2222 songbird58 tysontanx https://invent.kde.org/graphics/krita/-/commit/fa6e2c76a543ad9e5f69e53403e9acabfbb61127 0 oldest_to_newest 2328543 0 xeses16388 2024-06-17 01:01:49 +0000 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 2332655 1 penguinflyer2222 2024-06-27 14:28:56 +0000 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). 2333680 2 penguinflyer2222 2024-06-30 22:08:50 +0000 *** Bug 489518 has been marked as a duplicate of this bug. *** 2338222 3 dimula73 2024-07-18 12:04:01 +0000 Hi, Freya! Do you know, is it possible to reproduce this issue in an emulator? Or it is real hardware only? 2338379 4 penguinflyer2222 2024-07-19 00:07:38 +0000 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. 2338571 5 penguinflyer2222 2024-07-19 15:53:52 +0000 *** Bug 490505 has been marked as a duplicate of this bug. *** 2343863 6 penguinflyer2222 2024-08-07 14:11:56 +0000 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. 2346820 7 penguinflyer2222 2024-08-19 19:31:18 +0000 *** Bug 491912 has been marked as a duplicate of this bug. *** 2351103 8 halla 2024-09-03 12:47:15 +0000 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 2351107 9 tysontanx 2024-09-03 12:51:50 +0000 Thank you, Halla! :) 2351108 10 halla 2024-09-03 12:57:03 +0000 Sorry, but that was broken :-( 2360633 11 tysontanx 2024-09-28 05:28:56 +0000 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? 2360660 12 halla 2024-09-28 08:41:37 +0000 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. 2456516 13 dra.w.p.il.e+bugskde 2025-09-22 21:35:38 +0000 *** Bug 497103 has been marked as a duplicate of this bug. *** 2456535 14 tamtamy.tymona 2025-09-22 22:37:06 +0000 *** Bug 509748 has been marked as a duplicate of this bug. *** 2456698 15 dra.w.p.il.e+bugskde 2025-09-23 14:00:56 +0000 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 2456944 16 tysontanx 2025-09-24 01:27:06 +0000 Thank you, guys! :) 2467500 17 dra.w.p.il.e+bugskde 2025-11-03 06:08:05 +0000 *** Bug 511559 has been marked as a duplicate of this bug. ***