[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Krita performance.
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2013-05-22 18:52:18
Message-ID: CAEkBSfWfJFgX6nWrpmA-vs=-jFn3XVq=Gcu0HKNNnnYMZEk_SQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> I am fairly sure that photoshop does actually two or three things here:
>
> * keep the full data compressed
> * mipmapping
>
Some cache, yes. Not sure about the whole mipmapping.
> * do a kind of reverse composition first, like this:
>
> 1) for every screen pixel, determine the area of the image that is
> responsible for it.
> 2) go down the layer stack (not up, like we do), and check at which point
> that pixel becomes 100% opaque, possibly by simply using a nearest
> neighbour on every pixel in the area responsible for the display pixel, on
> the nearest mipmap. This is easy because their stack is fully linear, they
> don't have groups like we, and also no clone layers (as far as I can tell)
> 3) from that point, go up again
>
Well, our scheduler doesn't merge a layer if its extent doesn't intersect
the update area. I also did some experiments with merging only region() of
the paint device. It gives about 20% better performance on full refresh.
I'm not sure it gives much for usual painting though. I didn't push these
experiments, because they needed at least a week of work to change the
KisPainter this way.
Optimizing overlapping fully opaque areas... well, it might be a good idea.
But i'm not sure how much help it would be for us, because most of our
layers are either line-art or some (usually semi-transparent) coloring. We
need to calculate how many overlapping fully opaque areas we have on a set
of real-world images.
> Then, I am guessing, they start in the background to composite the full
> image and when that is done, scale it and show it.
>
Yep, that is true.
>
> Nuke works this way, too, and does it by scanlines. For every pixel in the
> scanline, get the area of pixels in the image resolution and calculate back
> and forth.
Is it like openGL calculates pixel values in the frame buffer?
> It's illuminating to read the nuke plugin coding docs.
>
Could you give a link to that?
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> </div>I am fairly \
sure that photoshop does actually two or three things here:<br> <br>
* keep the full data compressed<br>
* mipmapping<br></blockquote><div><br>Some cache, yes. Not sure about the whole \
mipmapping.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
* do a kind of reverse composition first, like this:<br>
<br>
1) for every screen pixel, determine the area of the image that is responsible for \
it.<br> 2) go down the layer stack (not up, like we do), and check at which point \
that pixel becomes 100% opaque, possibly by simply using a nearest neighbour on every \
pixel in the area responsible for the display pixel, on the nearest mipmap. This is \
easy because their stack is fully linear, they don't have groups like we, and \
also no clone layers (as far as I can tell)<br>
3) from that point, go up again<br></blockquote><div><br>Well, our scheduler \
doesn't merge a layer if its extent doesn't intersect the update area. I also \
did some experiments with merging only region() of the paint device. It gives about \
20% better performance on full refresh. I'm not sure it gives much for usual \
painting though. I didn't push these experiments, because they needed at least a \
week of work to change the KisPainter this way.<br> <br>Optimizing overlapping fully \
opaque areas... well, it might be a good idea. But i'm not sure how much help it \
would be for us, because most of our layers are either line-art or some (usually \
semi-transparent) coloring. We need to calculate how many overlapping fully opaque \
areas we have on a set of real-world images.<br> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
Then, I am guessing, they start in the background to composite the full image and \
when that is done, scale it and show it.<br></blockquote><div><br>Yep, that is true. \
<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">
<br>
Nuke works this way, too, and does it by scanlines. For every pixel in the scanline, \
get the area of pixels in the image resolution and calculate back and forth. \
</blockquote><div><br>Is it like openGL calculates pixel values in the frame \
buffer?<br> <br> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">It's illuminating to read the \
nuke plugin coding docs.<br clear="all"></blockquote><div><br>Could you give a link \
to that? <br> </div></div><br>-- <br>Dmitry Kazakov
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic