<br><br><div class="gmail_quote">On Fri, Mar 5, 2010 at 9:01 PM, <a href="mailto:LukasT.dev@gmail.com">LukasT.dev@gmail.com</a> <span dir="ltr"><></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Friday 05 March 2010 18:06:00 Dmitry Kazakov wrote:<br>
> > the flood fill is still slow even we optimzed the filling algorithm.<br>
> > Here is callgrind log of running krita with QPainter canvas<br>
</div>> > <a href="http://valdyas.org/%7Elukast/projection-floodfill.tar.gz" target="_blank">http://valdyas.org/~lukast/projection-floodfill.tar.gz</a><<a href="http://valdyas.org" target="_blank">http://valdyas.org</a><br>
> > /%7Elukast/projection-floodfill.tar.gz><br>
<div class="im">> ><br>
> > It seems like projection or pyramids are slow or something. The flood<br>
> > fill is<br>
> > also slow for OpenGL canvas. I will do the valgrinding.<br>
> ><br>
> > Dmitry, can you check it out?<br>
><br>
> I looked at it briefly. It seems like a plenty of time is spent to<br>
> KisPainter::bitBlt. New data manager api should fix this. But as for the<br>
> KisImagePyramid, i think it should be disabled for the release, as without<br>
> threading it is not much efficient.<br>
<br>
</div>I did the valgrinding of the OpenGL and QPainter canvas again so that I can<br>
compare and we discovered there a lot of time is spent by converting to LAB<br>
colorspace. So we can't do much about it probably. I discussed to change the<br>
difference method for pixels per colorspace but the best way to do the<br>
difference is to do it in LAB. I don't know if we can do something about<br>
speeding up our flood fill.<br></blockquote><div><br>Hmm.. How LAB is connected to flood filling? I just don't know... <br></div></div><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>