About mipmapping and further planning

[Boudewijn Rempt]

On Friday 09 July 2010, Dmitry Kazakov wrote:
> Hi!
> 
> I was considering implementation of mipmapping and i've finally come to a
> conclusion. We really needn't mipmapping! :P
> 
> Well, now in details. What the mipmapping technique is and what it isn't?
> Mipmapping is used for doing the scaling of textures fast. The main idea of
> the mipmapping is that we prepare the pyramid first, and then just use the
> same pyramid for wrapping onto objects of different sizes.

Don't forget that we also "zoom" when painting -- every rect that gets updated 
is zoomed. In Krita 1.6, we used nearest-neighbour sampling for zooming, which 
was pretty ugly, especially when doing line-art. In Krita 2.0 we have had 
several attempts at using a better scaling algorithm for the projection to fix 
that: 
http://www.valdyas.org/fading/index.cgi/hacking/krita/progress_2007_2.html

Mipmapping was introduced to make scaling faster while not losing quality. If 
we can have fast scaling of the projection for the qpainter canvas without

* quality loss when viewing a 12000x8000 image in fit-to-window mode
* without having a QImage the size of the projection

then I'm fine with removing the mipmapping.


> Boud said we need to be able to draw on big canvases efficiently. So i've
> made some measurements and got the following:
> 
> 1 layer. 2000x2000px. Pencil brush with radius 500px.
>  - bitBlt to canvas - 11.5%
>  - scaling down - 6.3%
>  - all the rest is paintOp's time (~80%)
> 
> 2 layers. 2000x2000px. Pencil brush with radius 500px.
>  - merge - 20 %
>  - bitBlt to canvas - 11%
>  - scaling down - 6%
>  - all the rest is paintOp's time (~60%)
> 

2000x2000 is not a big canvas, btw. 5000x3000 comes closer. The comic book 
artist usecase has 1000dpi A4 as its basic requirement, which comes to 
~12000x8000 pixels. 

> I've come to a conclusion that the optimization in the scheduler is still
> not perfect, because we still update the same areas many times.
> 
> So my nearest plans are:
> 
> 1) To adopt more complicated maths for the scheduler optimization

Ok.

> 2) The swapper (btw, what is the priority of it? how much do we need it?)

We need swapping both for undo and for really big images, so yet, having 
swapping has some priority for this gsoc.

And we need to completely get rid of the projection-sized QImage, of course.

-- 
Boudewijn Rempt | http://www.valdyas.org