Mipmapping for canvas. Ideas and comments.

[Dmitry Kazakov]

> Your work probably should be done at the projection level, not the prescaled
> projection level; the prescaled projection is only used to move pixels as
> quickly as possible to the canvas, and it is never bigger than the canvas size
> in pixels.

> I actually think you are working at too high a level here: I think a
> KisProjectionPyramid should be in krita/image, not krita/ui. Then the
> prescaled projection would resquest a QImage for the updated area at a certain
> zoom level, and the KMMP would return that, computed from the nearest tile.

> I'd suggest having KisProjectionPyramid in krita/image. So, if an area is
> recomposited, KisImage emits an sigImageUpdated(const QRect& rc) signal. It is
> connected to KisProjectionPyramid, which starts recomputing the pyramid for
> the tiles in the affected area (you have to have tiles here, you cannot cache
> the entire image in a QImage for every level). Through KisCanvas2,
> KisPrescaledProjection is notified and asks KisProjectionPyramid for the
> udpated area at the correct scaling level. KisProjectionPyramid takes the
> projection at the right mipmap level and returns a QImage at exactly the right
> zoom level, with KisPrescaledPProjection pastes in its cache and then asks the
> canvas to update.


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.

And why tiles? Why not QImage? Do you mean that an image can be much
bigger than a view?
At the moment, as i understood, KisProjectionCache doesn't take into
account any regionOfInterest.
Or do you mean that we shouldn't resample empty regions (tiles)?



> Question: have you taken a look at the way Gimp 2.6 has implemented its
> display pyramid? It is fairly simple and might be very instructive.

Shall take a look now.


> Yes, that sucks. But the if we implement region-of-interest in KisProjection,
> then we'd only filter the visible area of an image, and if the image isn't
> scaled down too much, it won't be too bad. I wonder whether GEGL optimizes for
> this.

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


> The real task of the prescaledprojection is have a QImage as big as the
> canvas, scaled to the current zoom level that can be used to blt to the
> QPainter canvas. It doesn't work with the OpenGL canvas (it is debatable
> whether it is necessary there, but the OpenGL canvas scaling down is pretty
> bad now because it uses simple nearest neighbour).
>

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?
As i read mipmapping appeared first from 3d world...
(of course, we need mipmapping when openGL is unavailable)


>> 2) Which  zoom-levels should  be stored inside  m_pyramid? I  saw that
>> when you  press Ctrl+'+'/'-' Krita switches across  some finite number
>> of levels. Which part of Krita/Koffice decides, which levels to use? I
>> guess, these levels and levels in m_pyramid should agree :)
>
> Traditionally, you'd take steps of 50%, so: 100, 50, 25, 12.5, I believe

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


-- 
Dmitry Kazakov