About mipmapping and further planning

[Sven Langkamp]

On Fri, Jul 9, 2010 at 8:40 PM, Tom M <letterrip at gmail.com> wrote:

> On Fri, Jul 9, 2010 at 6:43 AM, LukasT.dev at gmail.com
> <lukast.dev at gmail.com> wrote:
> > Zdrastvuj tavarish,
> >
> > On Friday, July 09, 2010 15:56:24 Dmitry Kazakov wrote:
> >> Hi!
> >>
> >> I was considering implementation of mipmapping and i've finally come to
> a
> >> conclusion. We really needn't mipmapping! :P
>
> You  are wrong :)
>
> As an extreme example, say you have a 30 GB image vastly zoomed out,
> and do a paint stroke with a large brush from one corner to the other,
> then rotate the image 45 degrees.
>
> With a properly designed mipmapping
>
> a) you don't need to load the 30GB image into memory at once, only the
> tiles and mipmaps needed at any one time and zoom level.
> b) during the stroke you update only the top layer of the mipmap, and
> store the stroke path/history, from the artists perspective they just
> did a paint stroke across a massive image and rotated a huge image,
> from the processors perspective it just did a trivial amount of
> painting.  You can propogate to lower levels either a) at your leisure
> b) when zoomed c) some combination of the former.
>
>
No, he is right. As Dmitry pointed out this usecase exists, but with the
current architecture is quite difficult to achieve that. Currently paint
operations aasume that the paint on the original image and not on a
scaled-down version.

The point is that even though it's useful in another context, it has some
limitations in Krita at the moment which make is less usefull for Krita.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100710/0ed61fb7/attachment.htm