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