<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
> PS: as an example of slowness: for small brushes, in Krita 2.3 I trace a<br>
> line of any width and it appears on the screen instantaneously, in 2.4 I<br>
> trace a line 5px wide and it appears on the screen approximately 1 second<br>
> later per 400 px of total line length.<br></div></div></blockquote><div> </div></div>Hi! Usually, valgrind is a good tool for searching for bottlenecks. For small brushes, there might be several reasons for a slowdown:<br>
<br>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.<br>
<br>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 =) )<br clear="all"><br><br>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.<br>
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].<br>
<br><br>[1] - <a href="http://s677.photobucket.com/albums/vv137/dimula73/?action=view&current=krita_graph2.png">http://s677.photobucket.com/albums/vv137/dimula73/?action=view&current=krita_graph2.png</a><br><br>-- <br>
Dmitry Kazakov<br>