About mipmapping and further planning

[Dmitry Kazakov]

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.

What do we have i Krita? Our "textures" are updated with every stroke, so
the pyramid will have to be rebuild after every transaction, that means that
we will have to do up to 30% more work. And what are the benefits of the
pyramid? There is only one, actually: "fast" zooming. Have you ever seen
slow zoom operation in Krita? Just try it! I've checked it today:
Ctrl-+/Ctrl-- on the image of 5000x5000px is performed in less than a
second. I think this is more than enough for most usecases.

There is one more usecase of the pyramid can be considered: working not with
originals of the image, but with its scaled-down copies.That is the thing
GEGL incorporates. This is really difficult to achieve due to differences in
architectures between Gegl and Krita (we will have to rewrite paintop and
filter framework for this).

Actually, there is one workaround for this rewriting. We can let our tools
work with originals of the layers. But merge of the layer stack will be
performed using scaled-down copies. The idea is good, but we will have to
decide, what to do with Adjustment Layers and Filter Masks? Not all of them
will be able to work with scaled images - so modifying of Filter API is
inevitable (we can include it into the plan, btw).

And the last thing: what is the usual zoom level artists work at? If it is
more than ~70% we will gain almost nothing form mipmaps.
(btw, this point can differ from Gegl's usecases - photographers are bounded
to the camera resolution, so they use much smaller zoom)



So, what do i propose? I think we should work and optimize some other
places. =)

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%)

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
2) The swapper (btw, what is the priority of it? how much do we need it?)

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100709/11f1dee6/attachment.htm