| Summary: | Performance drop with In-stack preview for Transform Tool | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Dorijan Salak <dorijan.salak> |
| Component: | Tools/Transform | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | dimula73 |
| Priority: | NOR | ||
| Version First Reported In: | 5.2.1 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Performance drop issue with transform tool | ||
|
Description
Dorijan Salak
2023-11-10 04:09:23 UTC
Hi, Dorijan! Could you please make a screen recording of the issue? I cannot reproduce it here locally :( Can it be that you change the zoom level of the document in between the transformations? It could result in a different level-of-detail of the image to be used for preview, which could result in a different speed... Created attachment 163487 [details]
Performance drop issue with transform tool
Happens with Accurate and Accurate with Instant Preview methods but not with Fast method. No noticeable performance drops if transformed content is only a small portion of the canvas size, has to be larger as shown in the screen recording. My movement speed both before transform and after are unchanged/similar as seen by the speed of cursor, but the content lags behind after transform (slight rotation in this case but anything causes performance drop). Adding new layer to the layer stack or deleting existing resets performance back to normal.
(In reply to Dmitry Kazakov from comment #1) > Hi, Dorijan! > > Could you please make a screen recording of the issue? I cannot reproduce it > here locally :( > > Can it be that you change the zoom level of the document in between the > transformations? It could result in a different level-of-detail of the image > to be used for preview, which could result in a different speed... Hi, Dmitry! As requested, I've uploaded screen recording to attachment. Not sure why it cannot be reproduced on your side nor why is it happening on my side but I know I can reproduce this 100% of the time and definitely doesn't look like a normal behavior especially because performance returns back to normal if I add new layer or delete existing one (as can be seen in recording). In case it might be useful info, specs: - CPU Intel i7 7700k - GPU Nvidia RTX 2080 Super - RAM DDR4 32GB 3000MHz - Storage Samsung 960 EVO 500GB NVMe For Krita settings I've tested with (both OpenGL and ANGLE) and without Canvas Acceleration, let Krita use all available cores and up to 24GB of RAM which is never even closely used. Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information. Just dropping in with more info. This turns out to be a slowdown caused by Continuous Transform functionality of transform tool, where it stores/recalls previous transform. Confirmed that hitting Esc button, Reset within tool options docker or choosing another tool will remove the performance drops. However the slowdown will resurface every time transform operation is done and again have to confirm any resize/scale/shear etc, then reset/Esc then moving will be faster. The part where performance returns to normal when adding/removing layer to the stack is due to the fact that this also resets previous transform. Unsure if this would still be considered a bug or "working as intended". It could be some issue with optimization in Continuous Transform or maybe this is the best it can be. Although in my opinion, it's weird that the performance drop is so impactful, where even a single pixel rotation/resize will make repositioning extremely slow. Hi, Dorijan!
The key point is this one:
> 3. Select layer with Free Transform tool and attempt to move it around, performance will be fine at first, then resize, rotate or something (don't resize too small or it won't be noticeable as much) and apply transform.
When you first activate a transform tool and try to move the layer, it does **not** do the transformation. It behaves as a move tool, i.e. just offsets the layer. As soon as you perform any real transformation action (like, rotation or scale), this fast-path optimization goes away and Krita starts to perform a fully-featured transformation, which is slow, since it starts to juggle with actual pixels.
And, yes, this behavior does not go away until you perform any **undoable** action. In your example you add/remove layers, which is an undoable action and resets the "continued" mode.
I don't think we can do anything about it. Raster transformations are slow. And we have a fast-path only for the non-transformed clips. That is the bug is not actually "performance drop", but "performance is too fast on activation of the tool" :)
|