<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