Slow flood fill with QPainter canvas

[Dmitry Kazakov]

On Fri, Mar 5, 2010 at 9:01 PM, LukasT.dev at gmail.com <> wrote:

> On Friday 05 March 2010 18:06:00 Dmitry Kazakov wrote:
> > > the flood fill is still slow even we optimzed the filling algorithm.
> > > Here is callgrind log of running krita with QPainter canvas
> > > http://valdyas.org/~lukast/projection-floodfill.tar.gz<http://valdyas.org/%7Elukast/projection-floodfill.tar.gz>
> <http://valdyas.org
> > > /%7Elukast/projection-floodfill.tar.gz>
> > >
> > > It seems like projection or pyramids are slow or something. The flood
> > > fill is
> > > also slow for OpenGL canvas. I will do the valgrinding.
> > >
> > > Dmitry, can you check it out?
> >
> > I looked at it briefly. It seems like a plenty of time is spent to
> > KisPainter::bitBlt. New data manager api should fix this. But as for the
> > KisImagePyramid, i think it should be disabled for the release, as
> without
> > threading it is not much efficient.
>
> I did the valgrinding  of the OpenGL and QPainter canvas again so that I
> can
> compare and we discovered there a lot of time is spent by converting to LAB
> colorspace. So we can't do much about it probably. I discussed to change
> the
> difference method for pixels per colorspace but the best way to do the
> difference is to do it in LAB. I don't know if we can do something about
> speeding up our flood fill.
>

Hmm.. How LAB is connected to flood filling? I just don't know...



-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100305/7d326d79/attachment.htm