https://bugs.kde.org/show_bug.cgi?id=526177
--- Comment #6 from anan zhou <[email protected]> --- Thank you for the explanation. I understand that some delay is expected when Krita has to recomposite a raster layer stack. I would like to clarify two important observations: 1. During my earlier tests with the Ubuntu-packaged Krita 6.0.1, the Ctrl+T transform preview in Fast mode followed the pointer smoothly, while the Move Tool remained severely delayed in the same document and session. This suggests that pointer input and screen presentation can be responsive, but the Move Tool’s live layer-update path behaves differently. 2. The attached video uses relatively slow dragging so that the separation is easy to see. When I drag the layer faster or repeatedly move it back and forth, the visible layer content falls much farther behind the bounding box. The delay becomes progressively more obvious and can reach a separation of hundreds of pixels, even in a new 1920 × 1080 document containing only one simple opaque paint layer. In the official Krita 6.0.4 AppImage, both the transform preview and the Move Tool were delayed in my test, while the Move Tool remained the consistently affected case across all tested versions. Canvas FPS can still remain around 70–150 FPS, and the behavior is identical with a mouse, touchpad, and tablet. Is this magnitude of accumulated delay for a single simple layer also considered expected? If the Move Tool cannot use the fast overlay path by design, would this be more appropriate as a performance issue or an upstream Mutter/Mesa report? -- You are receiving this mail because: You are watching all bug changes.
