Cache the reference paint device in the tools that use reference layers
This MR tries to solve BUG:457390, which is about caching the result of merging the reference layers (color labeled layers currently) in the tools that make use of them.
Explanation of the issue
The tools that use color labeled layers as reference have to perform two operations:
- Compute a merged device from the required color labeled layers (reference device).
- Actually perform the tool operation (fill, create selection, etc.).
The issue is that the reference device is recomputed at every user interaction with the tool. For big images that can be time consuming.
Explanation of the changes
What is required to solve the issue is to recompute the reference device only if any of the reference layers changed since the last user interaction.
A new step is needed that checks is those layers changed. If they did, then the reference device is recomputed; if they didn't then the last computed reference device is used.
For this the list of updated layers needs to be stored between iterations, so that the next iteration can check if the layers changed with respect to that.
This new step has to be performed also in the stroke. The reason is that if one checks in the GUI thread (the tool's beginPrimaryAction
, for example) if the layers changed, the last tool operation may not be finished, and that operation can change the reference layers. The result is that in the gui thread it seems that the layers didn't change, and the previous reference device is used.
So I changed the KisMergeLabeledLayersCommand
to also take into account a "previous reference device" and a "previous list of reference nodes". That way we can create a new list of reference nodes and compare it to the previous one, and the command can see if the new reference device has to be recomputed of it can be cloned from the previous reference device.
Formalities Checklist
-
I confirmed this builds. -
I confirmed Krita ran and the relevant functions work. -
I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!) -
I made sure my commits build individually and have good descriptions as per KDE guidelines. -
I made sure my code conforms to the standards set in the HACKING file. -
I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.