<br><br><div class="gmail_quote">On Fri, Oct 2, 2009 at 6:19 PM, Cyrille Berger <span dir="ltr">&lt;<a href="mailto:cberger@cberger.net" target="_blank">cberger@cberger.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>On Friday 02 October 2009, Boudewijn Rempt wrote:<br>
&gt; We have had a single-paint device api before, and  that didn&#39;t work out<br>
&gt; either.<br>
</div>I think it was at a time when copying data was (considered) too expensive. But<br>
the src,dst has always been just half working.</blockquote><br><div><br>What do you mean by &quot;half-working&quot;?<br><br><br><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;">

cheap copying of data (or even<br>
better, no copy at all with shared tiles).<br>
</blockquote></div><br>Cheap copying can be easily done by tile-manager (at least in tiles3). Especially if we needn&#39;t set extent() of a newly created device exactly. I mean, if we ask to copy some rect, for example (10,10 60x60), we can easily copy a bit more than was requested (0,0 128x128). This operation will simply create a set of shared tiles, those will be pre-cached by a tile-pooler quite fast.<br>

<br>We could call those operations like:<br>cloneDevice(QRect rc) - can clone a bit more<br>cloneDeviceExactly(QRect rc) - crops the area that was not requested.<br><br><br><br>BUT, there is a heavy disadvantage in this (&quot;easy duplication&quot;) approach.<br>

<br>Clone operation will still be quite expensive, because of creation of a hash-table. It&#39;s size is quite big now and it&#39;s tends to be even bigger in the future. It is &gt;8192 bytes on 32-bit and &gt;16386 bytes on 64-bit machine now. Just imagine, to make a copy of a couple of pixels, you&#39;ll have to allocate that much.<br>

<br><br>Well, it doesn&#39;t mean that we shouldn&#39;t use shared copies at all, it just means that we should think well before introducing yet another clone of data and try to eliminate them at all.<br><br><br><br clear="all">
<br>-- <br>Dmitry Kazakov<br>