About mipmapping and further planning

Sven Langkamp sven.langkamp at gmail.com
Sat Jul 10 13:05:46 CEST 2010


On Fri, Jul 9, 2010 at 3:56 PM, Dmitry Kazakov <dimula73 at gmail.com> 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.
>
> 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).
>

I think it would be better to decide in a case by case way. For example we
have some filter that can run on a scaled-down version like most color
adjustments. Since these are very common filters this would give us a big
speedup. In other case the filter would fallback to original.
To avoid these fallbacks it might be a good idea to limit adjustment layers
and filter masks to the filters that can do the shortcut.

For the paintops: What would it require to get a paintop to work with
mipmapping? Maybe we would just special case for the most common paintops
like pixel brush to enable them to paint on a scale-down version. It would
be just an approximation, but it might be worth the work if it's close
enough to the real result.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100710/c1f7d52b/attachment.htm 


More information about the kimageshop mailing list