Krita useable for Blender movies

[Dmitry Kazakov]

> So I'm starting this discussion to point out what can be done, what is
> slow,
> how you see the problem?
>

How i see it:

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). =)

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].

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.

Of course, Qt may smooth this comparison procedure a bit with shared
internal data, but nevertheless integer switch should be much faster than
that.

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.

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. 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).

I'm working on a layers merging parallelization right now. The same
algorithm can (and should) be used in KisView for pre-scaling.


4) openGL is good, but i think we could use processor's capabilities like
SSE and friends first.


[1] - libs/pigment/colorspaces/KoRgbU8CompositeOp.cpp:65



PS:
I don't want to say the tile engine shouldn't be optimized itself, i mean
it's API should be optimized first.

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