<br><br><div class="gmail_quote">On Fri, Oct 23, 2009 at 4:45 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>></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 class="im">On Friday 23 October 2009, Dmitry Kazakov wrote:<br>
<br>
> 1) I wouldn't say it's a tile engine internal fault that Krita is slow. I'd<br>
> even say that it's not tile engine's fault at all (mostly). =)<br>
<br>
</div>Depends a bit on which tile engine you're talking about -- the currently<br>
active one has that nasty lock that kicks in whenever a tile is accessed. This<br>
effectively serializes everything in Krita </blockquote><div><br>I wouldn't say so =)<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;">
-- see the mutrace output I posted<br>
a while ago. The second one doesn't support swapping, so it's not comparable.<br>
<br>
And I am sure there is a lot left to improve for both tile engines, if even<br>
the Gimp people found some serious issues in their decades old tile engine<br>
this year.<br></blockquote><div><br>Of course we should optimize it! I mean that we should design an "optimal" API first! ;)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Right now, the easiest win we can make in the tile engine is to make the<br>
iterators cache the tiles they are accessing in a row or column. That's<br>
something that has been borne out by proper profiling.<br></blockquote><div><br>Yes, it could be done.<br><br> </div><div> </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">
> Most problems come from *misusing* the engine. And the biggest problem here<br>
> is bitBlt'ing at higher level of abstraction (colorspaces). We used to<br>
> discuss it on irc, as i remember. Tile engine (at least new one) supports<br>
> implicit tile sharing and lazy copying, BUT higher layers of abstractions<br>
> do not use it at all! They must use it when source and destination<br>
> colorspaces coincide, it'll be much faster than direct copying of data<br>
> stride by stride.<br>
><br>
> But to solve this issue we need to design a good programming interface for<br>
> it.<br>
> The implementation will not be that difficult, i can do this as soon we<br>
> discuss the interface. We could discuss it on sprint?<br>
><br>
><br>
> 2) To make bitBlt'ing more faster we should solve another one issue:<br>
> compositeOps constants in pigment.<br>
><br>
> I don't know how it happened, but all the compositeOp constants (like<br>
> COMPOSITE_OVER) are strings! And for every stride of the image (there might<br>
> be more than 1000 strides per image) we do a string comparison! More than<br>
> that, we do many string comparisons on every composition! See [1].<br>
<br>
</div>No, we don't. We get a KoCompositeOp subclass instance and apply that. It's<br>
easy enough to see that we don't do all those string comparisons by running<br>
valgrind.<br>
<div class="im"><br>
> I don't know where COMPOSITE_OVER and COMPOSITE_ALPHA_DARKEN are<br>
> implemented, maybe their application is optimized a bit, but most of the<br>
> others should suffer from this comparison.<br>
<br>
</div>For rgbu8, ADD, ALPHA_DARKEN, BURN, DIVIDE, DODGE, ERASE, MULTIPLY, OVER,<br>
OVERLAY, SCREEN, SUBTRACT are implemented as separate, templated classes.<br>
<br>
COMPOSITE_DARKEN, COMPOSITE_LIGHTEN,COMPOSITE_HUE,<br>
COMPOSITE_SATURATIONCOMPOSITE_VALUE, COMPOSITE_COLOR, COMPOSITE_IN<br>
COMPOSITE_OUT, COMPOSITE_ADD, COMPOSITE_DIFF COMPOSITE_BUMPMAP,<br>
COMPOSITE_CLEAR, COMPOSITE_DISSOLVE are implemented in this legacy code.<br>
<br>
Other colorspaces do not have the legacy code path.<br>
<div class="im"><br>
> Of course, Qt may smooth this comparison procedure a bit with shared<br>
> internal data, but nevertheless integer switch should be much faster than<br>
> that.<br>
<br>
</div>It is optimized a lot in Qt -- and don't forget that these are const's. But,<br>
as Cyrille has said, it's old code.<br>
<div class="im"><br>
><br>
> What do i suggest?<br>
> Change all these constants' type to qint32 and create separate function<br>
> that would show their name using integers. This chain of if()<br>
> constrictions in [1] could be replaced with a simple 'switch'<br>
> construction. Theoretically, a compiler can optimize this switch with a<br>
> jump table at asm level.<br>
<br>
</div>That's not necessary because we've already implemented something like Thomas<br>
Zander suggested three years ago. We just haven't had the time to port all<br>
code.<br>
<div class="im"><br>
> 3) Slow work on dual-core processors is connected with the fact that there<br>
> almost no threading in Krita at the moment. =) Yes, we have KisImageUpdater<br>
> but it does almost nothing for speed, because while it works other parts of<br>
> Krita (e.g. KisView) are waiting for his work finished.<br>
<br>
</div>KisView is not waiting in the sense that it blocks until the image is<br>
refreshed. The gui is kept responsive at all times because the recomputation<br>
isn't in done in the gui thread. Note that actually painting, i.e., making<br>
strokes, also involves running a thread, which means there are 3 threads<br>
running already while painting.<br>
<div class="im"><br>
> It means that Krita<br>
> is almost single-threaded: while one thread is working, others - are<br>
> waiting. I saw it when i started a system monitor in parallel with Krita,<br>
> it showed that only one core is working at the same moment (i tested it<br>
> about a month ago).<br>
<br>
</div>When painting with a big brush (~500) pixels, kysguard shows that both cores<br>
are actually saturated. One is recompositing, the other is computing the 500<br>
pixel mask for every dab (which is the biggest measurable performance issue we<br>
have).<br>
<div class="im"><br>
> I'm working on a layers merging parallelization right now. The same<br>
> algorithm can (and should) be used in KisView for pre-scaling.<br>
<br>
</div>That sounds cool! But please -- no enormous code drops, make sure we have a<br>
manageable set of small patches for review!<br>
<div class="im"><br>
> 4) openGL is good, but i think we could use processor's capabilities like<br>
> SSE and friends first.<br>
<br>
</div>I'm vacillating on this... sse etc. are nice, but most distributors do not<br>
enable them by default, except for the 64 bits systems. </blockquote><div><br>But not all systems support hardware opengl, do they?<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;">
OpenGL + glsl has<br>
the potential to give much more performance, but I haven't got a system where<br>
I can use it. And if we can move more and more work to opengtl, we can profit<br>
from the automatic optimization it gives us.<br>
<div class="im"><br>
<br>
--<br>
Boudewijn Rempt | <a href="http://www.valdyas.org" target="_blank">http://www.valdyas.org</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">kimageshop mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>