Krita performance.

[Boudewijn Rempt]

On Wednesday 22 May 2013 May 10:16:30 Dmitry Kazakov wrote:
> > So, I guess, we could implement a kind of scaled down cache in the
> >> KisImage. Then some actions (which are designed to support it) may be
> >> applied by the strokes framework first on the scaled down image and later
> >> on the original one. As stroked framework works in the background the UI
> >> will not be blocked during these actions.
> >>
> >
> > I think you this would need to go through the entire layer stack.
> >
> 
> Yes, sure. That's why I suggest doing an optimization of the stack and of
> the cache stack. And if we want to implement this incrementally, we could
> first implement a single-node cache and then extend it to a graph.

I am fairly sure that photoshop does actually two or three things here:

* keep the full data compressed
* mipmapping
* do a kind of reverse composition first, like this:

1) for every screen pixel, determine the area of the image that is responsible for it.
2) go down the layer stack (not up, like we do), and check at which point that pixel becomes 100% opaque, possibly by simply using a nearest neighbour on every pixel in the area responsible for the display pixel, on the nearest mipmap. This is easy because their stack is fully linear, they don't have groups like we, and also no clone layers (as far as I can tell)
3) from that point, go up again

Then, I am guessing, they start in the background to composite the full image and when that is done, scale it and show it.

Nuke works this way, too, and does it by scanlines. For every pixel in the scanline, get the area of pixels in the image resolution and calculate back and forth. It's illuminating to read the nuke plugin coding docs.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl