Skip to content

Fix Cache Flush Problems On `Layer > Transform` Operations (BUG 424111)

Eoin O'Neill requested to merge (removed):krita/4.3-B424111 into krita/4.3

BUG:424111

Currently, node transform operations won't flush the cache which causes an odd behavior when scrubbing scaled layers (layer visuals would pop between the old size and the new size.)

This is a solution, but not a flawless one due to the following:

Withstanding Issues

  • Doesn't work when undoing Layer > Transform operations.
  • I don't like the introduction of a new function in paint device solely for flushing the frame cache for all frames affected by the current active frame.

Questions

For @dkazakov or anyone who might know...

  1. KisUndoAdapter is being used here to wrap this transformation behavior into a command so that Krita can undo / redo this operation. So when it comes to flushing the frame cache, I suppose I could create a new command that clears the cache (for the span of the modified layer) entirely and append that to the parent undo. I'm not sure if that's the right idea when it comes to the KisUndoAdapter though. This might still require the added KisPaintDevice::requestRegenerateCurrentFrameCache for flushing all of the cache of a given paint device. Would this be an appropriate way to solve this undo/redo dilemma?

  2. KisTransactionData seems to be tied into this functionality, but I don't have a great understanding of what its task or purpose is (Outside of it being responsible for updating tiles in a undo/redo compliant fashion.) Tracking the usage makes it somewhat more nebulous, since it seems to be used in a few different paint device operations. Could the cache clearing happen here instead?

  3. A general question regarding frame caching -- I think that it's an issue that any paint device updates don't automatically flush the animation cache. There are some cases where this makes sense (for instance, loading a new keyframe) but there are other instances where cache clearing has to be manually invoked which leads to some error-prone design. Is there some way we could address this?

Edited by Eoin O'Neill

Merge request reports