Speed of Krita 2.4

[Dmitry Kazakov]

> > PS: as an example of slowness: for small brushes, in Krita 2.3 I trace a
> > line of any width and it appears on the screen instantaneously, in 2.4 I
> > trace a line 5px wide and it appears on the screen approximately 1 second
> > later per 400 px of total line length.
>

Hi! Usually, valgrind is a good tool for searching for bottlenecks. For
small brushes, there might be several reasons for a slowdown:

1) Recently, we activated a new setDirty(QVector<QRect>) signals, so it
might be a reason. To check this you can edit KisPainter::takeDIrtyRegion()
to return a united rect instead. But you'll need some stable method of
measurement for this.

2) I had such problem when I forgot to disable assert checks and tested
Dedug build =). RelWithDebInfo should be ok, I guess (Cyrille will correct
me if i'm wrong =) )


You can measure the brush painting speed with the stroke benchmarks. But if
they show the same results, then the problem might be in some update code.
Then you can try the following.
Recently, I've worked on a class for measurement the brush resposiveness. It
measures the time when the painting and update (in the scheduler) are
finished. You can use this class for comparison of different versions as
well. And you can extend it to measure scaling in the KisPrescaledProjection
as well. The class is called KisUpdateTimeMonitor and it is placed in a
branch response-measure-old-kazakov. But this class doesn't give you the
'avarage speed', it gives you a graph response_time=f(mouse_speed). Like
this [1].


[1] -
http://s677.photobucket.com/albums/vv137/dimula73/?action=view&current=krita_graph2.png

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