[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: koffice/krita/image
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2009-10-04 18:46:51
Message-ID: ae32c1ef0910041146o18d57a1ey4fce9ee5db7bee5d () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>
> Keep in mind that with double-paintdevice we iterate twice, and can't use
> KisRectIterator but have to use the much slower KisH/VLineIterator (until
> they
> are fixed to cache tiles, but I am rather sure the Rect one will remains
> fater).
>
Hm.. Maybe you are right, though i don't understand you fully =)
If you have a single-paintdevice system, nevertheless you have to create
_two_ iterators: one for read and one for write, what is the difference with
double-paintdevice system? Could you explain it a bit more?
> And I also said that we need to investigate making copy cheaper, with for
> instance copy-on-write tiles for when you clone paint device, but could
> probably be usefull when bitBlting a copy. So the 2nd, could just be made
> by
> having a PaintDevice pointing to the old tiles, and I expect that operation
> to
> be reasonnably cheap.
>
Ermm.. That is exactly the thing i was writing two letters above :)
We can't make it infinitely cheaper, because _creation_ of a datamanager
object is quite expensive operation itself (because of initial creation of a
hash table (see two letters above)).
Adding shared tiles to a bitBlt operation is an extremely good idea, but it
should take into account colorspaces. Do you have an idea how to solve this?
(we could discuss it on sprint)
> I have been a strong advocate of the src/dst API, based on the assumption
> that
> copying was expensive, and that for features such as masks or paint with
> filter
> the copying would be a burden. But now, based on the experience we have
> build
> with that API, I see significant drawback:
> 1) not possible to use KisRectIterator
>
Isn't it possible to fix KisRectIterator instead?
> 2) double the number of tiles retrieval (or even mutliply the number of
> retrieval by 2*64 for the current non optimized KisH/VLineIterator)
>
How is it connected to an API? Could you explain?
> 3) confusing API, since iterators already include a src/dst mechanism with
> the
> oldRawData/rawData functions, and as we can see it, making filters work
> correctly with that API is quiet difficult
>
oldRawData/rawData are not src/dst really. They are oldRawData and rawData
actually! :)
> The drawback of having single-src:
> 1) the need to first copy the data
>
> But if copy get cheap, and I trully think it can be cheap, then I think we
> can
> get significant improvement. Both API and performance wise.
>
Please read above.
But in this very case, cheap copy would help, because we already create
additional paintDevice nevertheless.
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<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;">Keep in mind \
that with double-paintdevice we iterate twice, and can't use<br>
KisRectIterator but have to use the much slower KisH/VLineIterator (until they<br>
are fixed to cache tiles, but I am rather sure the Rect one will remains<br>
fater).<br></blockquote><div><br>Hm.. Maybe you are right, though i don't \
understand you fully =) <br><br>If you have a single-paintdevice system, nevertheless \
you have to create _two_ iterators: one for read and one for write, what is the \
difference with double-paintdevice system? Could you explain it a bit more?<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;"> And I also said that we need to \
investigate making copy cheaper, with for<br> instance copy-on-write tiles for when \
you clone paint device, but could<br> probably be usefull when bitBlting a copy. So \
the 2nd, could just be made by<br> having a PaintDevice pointing to the old tiles, \
and I expect that operation to<br> be reasonnably \
cheap.<br></blockquote><div><br>Ermm.. That is exactly the thing i was writing two \
letters above :)<br><br>We can't make it infinitely cheaper, because _creation_ \
of a datamanager object is quite expensive operation itself (because of initial \
creation of a hash table (see two letters above)).<br> <br><br>Adding shared tiles to \
a bitBlt operation is an extremely good idea, but it should take into account \
colorspaces. Do you have an idea how to solve this?<br>(we could discuss it on \
sprint)<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;">
I have been a strong advocate of the src/dst API, based on the assumption that<br>
copying was expensive, and that for features such as masks or paint with filter<br>
the copying would be a burden. But now, based on the experience we have build<br>
with that API, I see significant drawback:<br>
1) not possible to use KisRectIterator<br></blockquote><div><br>Isn't it possible \
to fix KisRectIterator instead?<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;">
2) double the number of tiles retrieval (or even mutliply the number of<br>
retrieval by 2*64 for the current non optimized \
KisH/VLineIterator)<br></blockquote><div><br>How is it connected to an API? Could you \
explain?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) confusing API, since iterators already include a src/dst mechanism with the<br>
oldRawData/rawData functions, and as we can see it, making filters work<br>
correctly with that API is quiet difficult<br></blockquote><div><br>
oldRawData/rawData are not src/dst really. They are oldRawData and rawData actually! \
:)<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;">
The drawback of having single-src:<br>
1) the need to first copy the data<br>
<br>
But if copy get cheap, and I trully think it can be cheap, then I think we can<br>
get significant improvement. Both API and performance \
wise.<br></blockquote><div><br>Please read above.<br>But in this very case, cheap \
copy would help, because we already create additional paintDevice nevertheless.<br \
clear="all"> </div></div><br>-- <br>Dmitry Kazakov<br>
_______________________________________________
kimageshop 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