Kurt,

Someone reported for my builds that turning off color management helped. However, for photographs I would not want to turn off color management. They did say they were OK with my 2.7.5 build

Partha

On Tue, Apr 10, 2012 at 7:11 PM, Kurt Pruenner wrote:

Hi,

I just downloaded Jernej Simončič's windows build of 2.8.0-RC1 and found that both on my tablet running Windows 7 with Intel HD3000 graphics as well as on my desktop, also running Windows 7 but with an ATI Radeon 5870, panning around an image looks really weird once you pan too fast:

http://img441.imageshack.us/img441/6317/gimppanartifacts.jpg

A screenshot doesn't really do it justice, though, so I've also made a ~30 second screen capture video:

http://youtu.be/gpARpvEDH0Y?hd=1

I'm just holding down the middle mouse button and panning the 100% zoomed image around.

The same thing also happened using one of Partha's recent 2.7.x builds.

Does anyone else get similar results? Panning in 2.6.x was smooth as butter for me... :/

--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria

np: Thomas Fehlmann - Next To The Field (Pop Ambient 2007) _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

... I'm packaging GIMP for Mac OS X and can confirm this behaviour too. If color management is enabled, redrawing the picture, eg. switching the visibilty of a layer, gets horrible slow.

This is somehow related to first doing color correction and then scaling the image down. If I open a photo with e.g. 4800 x 3200 pixels, set zoom to 15%, add a some layer, GIMP redraws the screen very slow. If I set zoom to 100% without changing the size of the image window, redrawing is much faster.

AFACIS at 100% zoom only the visible part of the image is used for color correction. At 15% zoom, the whole image is visible, and so all pixels are processed although the image is scaled down to fit into the image window.

IMO color management routines should be done on the already zoomed down view. There should be no visible difference to the actual behaviour if you do so, but it will be much faster.

Simone

Am 11.04.2012 um 08:43 schrieb Kurt Pruenner:

On 11.04.2012 01:33, Partha Bagchi wrote:

Someone reported for my builds that turning off color management helped. However, for photographs I would not want to turn off color management. They did say they were OK with my 2.7.5 build

I'm afraid turning off color management didn't make the slightest difference...

I've also just confirmed that I get the same artifacts on my notebook at work, so that's 3 64-bit Windows 7 machines with horrible panning performance... :(

By the way - is it somehow possible to install the 32-bit version of GIMP 2.8.x on a 64-bit system with the new combined Windows installer?

On Tue, Apr 10, 2012 at 7:11 PM, Kurt Pruenner wrote:

Hi,

I just downloaded Jernej Simončič's windows build of 2.8.0-RC1 and found that both on my tablet running Windows 7 with Intel HD3000 graphics as well as on my desktop, also running Windows 7 but with an ATI Radeon 5870, panning around an image looks really weird once you pan too fast:

http://img441.imageshack.us/img441/6317/gimppanartifacts.jpg

A screenshot doesn't really do it justice, though, so I've also made a ~30 second screen capture video:

http://youtu.be/gpARpvEDH0Y?hd=1

I'm just holding down the middle mouse button and panning the 100% zoomed image around.

The same thing also happened using one of Partha's recent 2.7.x builds.

Does anyone else get similar results? Panning in 2.6.x was smooth as butter for me... :/

--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria

np: Thomas Fehlmann - Next To The Field (Pop Ambient 2007) _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Thu, Apr 12, 2012 at 2:12 PM, Simone Karin Lehmann wrote:

AFACIS at 100% zoom only the visible part of the image is used for color correction. At 15% zoom, the whole image is visible, and so all pixels are processed although the image is scaled down to fit into the image window.

IMO color management routines should be done on the already zoomed down view. There should be no visible difference to the actual behaviour if you do so, but it will be much faster.

I think this is already the case, the problem is probably that the display is being updated too frequently - thus the same pixels being changed multiple times rather than too many pixels being transformed.

When a single 64x64 tile changes and you have zoomed out to 25% only a 16x16 area of the screen should need to be updated. It might be that GIMP is dirtying the next two levels of mipmap up. In that case leading to 16x as many re-conversions as strictly neccesary.

If each of these X's represent a 64x64 tile, this is 100% or 1:1:

XXXX XXXX
XXXX

Zoomed to 50% this would be represented by 4 scaled down tiles:

XX XX

Which at 25% and below is one tile that is to be shown on screen.

X

If changes to this 25% scale tile cause a full re-update of the screen area it covers, and we succesively change just one and one tile at the 1:1 level we will end up recomputing the transform for every pixel in the image 16 times,. at 12.5% zoom level and below it would be 64 times. The color conversion done with lcms is already expensive doing it an excessive amount of times will make it even worse.

(I have not fully confirmed that this is how things behave, but based on observations and some slight profiling this is my best guess.)

It should also be noted that if GIMP is using color management because it picked up a globally set, _and_ used color profile then you most likely are better off working directly in sRGB in GIMP with color management disabled. Letting colord / gnome-color-manager or similar do it's job of adjusting sRGB according to your displays profile. Having both global color correction and GIMP's display filter would lead to double correction and thus incorrect results.

/yvind K.

The future is already here. It's just not very evenly distributed
                        -- William Gibson
http://pippin.gimp.org/              http://ffii.org/
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list