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