Histograms & changing layers
Bart Coppens
kde at bartcoppens.be
Mon Jan 9 22:34:39 CET 2006
On Monday 09 January 2006 22:10, Boudewijn Rempt wrote:
> The histogram docker is what makes changing layers very slow at the moment,
Right! The histogram shouldn't even update when we switch layers in the
layerbox, only when we change one.
> especially if there is a largish number of layers, so I thought I'd take a
> look at this. However, I cannot find where we connect the changing of
> layers to any activity in the histogram docker... Where do we do that?
My guess is it emits either sigColorSpaceChanged, or sigImageUpdated(the
complete rect) when changing layers. The first one is in histogramdocker.cc,
line 83, the latter is kis_imagerasteredcache.cc, line 50.
Either one of those will trigger a complete re-adding of all 'raster parts' to
the cache, which is the slowness that is apparent. My first attempt for this
code actually used a QApp -> processEvents or so, to ensure that it doesn't
lag, but this was deemed 'unsafe' by many.
It was suggested, that if need be, we could use a QTimer::singleShot(0) to
'emulate' it in a safer way. I decided against it, because I had the
impression that it did not have a real performance impact, and the code would
be a lot more difficult (since that trick needs the double for-loop to be
broken completely apart). Obviously that was wrong.
The code you probably seek (if those 2 signals still need to be emitted), is
KisImageRasteredCache::imageUpdated in kis_imagerasteredcache.cc.
Bart Coppens
More information about the kimageshop
mailing list