<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> An issue with "m_projection requests _changed_ tiles" could be done with<br>
> tile-versioning. Every tile could have a revision that was used by KisImage<br>
> to keep the projection up-to-date. But it's quite difficult to implement<br>
> and we have to think over it properly.<br>
</div>Hm... Yes, that sounds pretty complicated.<br>
</blockquote><div><br>
It could use Qt-signals, maybe. Are they queued? Well, i'll think it over at my leisure =)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> I think it's not the worst problem. By the way where this paint device<br>
> moving used?<br>
</div>Whenever you move a layer using the move tool.<br>
</blockquote><div><br>
Now i see. <br>
There is an potential for future expansion: moving paint device across tiles in background... <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> So to say, can two KisPaintLayers be merged tile by tile?<br>
</div>Yes, provided the origin is the same.<br>
</blockquote></div>Sounds promisingly :)<br>
<br>
Well, i submitted my proposal last Sunday.<br>
<a href="http://socghop.appspot.com/student_proposal/show/google/gsoc2009/dmitryk/t123835355302">http://socghop.appspot.com/student_proposal/show/google/gsoc2009/dmitryk/t123835355302</a><br>
<br>
I think it's quite detailed. Did i forget something?<br><br clear="all"><br>-- <br>Dmitry Kazakov<br>