Mipmapping for canvas. Ideas and comments.

Boudewijn Rempt boud at valdyas.org
Wed Jul 22 18:39:14 CEST 2009

On Wednesday 22 July 2009, Dmitry Kazakov wrote:

> The reason why i wanted to add it to prescaled projection - i didn't
> want to add an additional layer of abstraction (additional obstacle in
> image's way). It can create an additional delay before returning
> scaled image. KisPrescaledProjection won't get an image until
> KisProjectionPyramid finishes build of all images.

Well, splitting would mean two classes, but also a clear separation of 
concerns: KisPrescaledCache would have the right cache for the canvas, 
KisProjectionPyramid would be responsible for scaling.

KisPrescaledCache is already one of the thorniest classes in Krita, adding 
stuff there is really not recommended.

> And why tiles? Why not QImage? Do you mean that an image can be much
> bigger than a view?

Right now we cache the entire image in a QImage (up to a particular size). 
That takes a lot of continguous memory, and is already something that's on the 
todo to change. And with larger images it won't work at all. Much better to 
cut that out cleanly and design a KisProjectionPyramid that uses tiles.

> At the moment, as i understood, KisProjectionCache doesn't take into
> account any regionOfInterest.

I originally intended KisProjectionCache to use tiles. But it should have 
access to the whole image, not just the visibile area, it's not the place 
where roi is interesting, since it doesn't do much work. The please where roi 
is interesting in KisProjection, where rects within the roi should be 
recomposited first, and rects outside the roi after those inside are done.

> Or do you mean that we shouldn't resample empty regions (tiles)?

No, thought it's an idea to check whether a tile (which is not the same thing 
as a tile in the tilemanager!) in the projection is empty or not, and then not 
scale that. That could help a lot, right now the scaling algorithm happily 
scales a white qimage with as much effort as a complex painting.

> It won't help with photos and current camera's "megapixels" =(
> (Yes it's no Krita's "region of interest", but...)

:-). It will help if you don't keep the whole image in view, but apply a 
filter at 100% zoom.

> Well, it seems that KisImage level really fits better.
> Btw, doesn't OpenGL has it's own _hardware_ downsampling? Or even
> mipmapping? I guess it's quite unreasonably to emulate mipmapping with cpu
> when gpu can do it faster?

Lukas is looking into that.

> As i read mipmapping appeared first from 3d world...
> (of course, we need mipmapping when openGL is unavailable)

> I wanted to have some optimization for usual scales, eg. 100,75,50,25 =)

Oh, that's ok too -- i think the levels are usually take to make it easy to 
scale, i.e, you always need a whole number of input pixels for the output 
Boudewijn Rempt | http://www.valdyas.org

More information about the kimageshop mailing list