Image update strategy

[Sven Langkamp]

On Fri, Apr 4, 2008 at 7:05 PM, Emanuele Tamponi <emanuele at valinor.it>
wrote:

> Hello,
> As I was trying to say to boud in IRC, in these days I had a simple idea
> on
> how to manage in a "easy" way the layering that occours when a KisImage
> needs
> a repaint. boud assured me that the current strategy has a strong
> infrastructure, so I don't want to propose a "substitute", but just a
> suggestion and if you consider it a really good solution, we can take into
> account even the substitution.
>
> Anyway, now I'll try to explain; as often happens with my explanations,
> I'm
> sure that it will be of almost no use, but still... perhaps with a few
> images
> and some code I'll be a bit more successful :) Let's start.
>
> Consider a multi-layered image as in this picture:
>
> <picture1>
>
> Each rect is a layer. When this image is being built, a method finds all
> the "simple" (as in not-more-decomponible) regions of the image:
>
> <picture2>
>
> In this example, as you see in the picture, there are 4 regions. Each
> "region
> object" should contain a list of layers that it contains, from the
> bottommost
> to the topmost (so in a bottom-up order)
>
> Region 1: Layer I
> Region 2: Layer I and II
> Region 3: Layer I, II and III
> Region 4: Layer I and III
>
> These region objects calculate a list of the layers that are *visible* in
> their region. In the example, consider layer III being completely opaque,
> while layers I and II are semi-opaque; and consider layer order being I,
> III,
> II (from bottom to top). Then:
>

Isn't it very unlikely that an image contains a completely opaque layer?
Even if you take the exact bounds there could be holes inside the layer.
And scanning for the biggest opaque rect could be very slow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20080404/e9716c95/attachment.html