koffice/krita/image

[Dmitry Kazakov]

On Fri, Oct 2, 2009 at 6:19 PM, Cyrille Berger <cberger at cberger.net> wrote:

> On Friday 02 October 2009, Boudewijn Rempt wrote:
> > We have had a single-paint device api before, and  that didn't work out
> > either.
> I think it was at a time when copying data was (considered) too expensive.
> But
> the src,dst has always been just half working.



What do you mean by "half-working"?




cheap copying of data (or even
> better, no copy at all with shared tiles).
>

Cheap copying can be easily done by tile-manager (at least in tiles3).
Especially if we needn'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.

We could call those operations like:
cloneDevice(QRect rc) - can clone a bit more
cloneDeviceExactly(QRect rc) - crops the area that was not requested.



BUT, there is a heavy disadvantage in this ("easy duplication") approach.

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


Well, it doesn't mean that we shouldn'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.




-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20091002/fe4619bc/attachment.htm