LR 4.1: Performance anomaly in crop mode

  • 1
  • Problem
  • Updated 7 years ago
  • Acknowledged
Load a reasonably sized (~10MP) JPEG or TIFF in develop module and enter crop mode. Crop away a portion of the image. Now move the canvas...
- using mouse: Ok, canvas follows mouse almost instantaneously
- using arrow keys: Also Ok, almost no delay between key press and movement of canvas
- using arrow keys plus alt key: very slow, canvas follows with delay of about 1 second
- using arrow keys plus shift key: Same as for alt key

During the ~1s delay, CPU load is equivalent of ca. 1 constantly running thread (12%...13% on 8 cores).

Curiously, this anomaly does *not* occur for raws (at least 40D CR2) [Correction, see update 3 below]. I didn't try DNG and PSD. It does not seem to depend on development settings, size or location of crop rectangle, or display size (i.e. same behaviour if the LR windows is made very small).

Not a big deal, but it can be annoying when fine-tuning the crop using alt plus arrow keys.

LR 4.1 64 Bit on Win7, 16GB RAM, Processor: i7-2600 3.40GHz. Video: NVIDIA GeForce GT 520, latest driver.

Update: On a second user account on the same machine, the problem does not occur. I am puzzled. Which different setting or other thing may cause that? Both catalogs are relatively small (test catalogs) and are both optimized.

Update 2: I deleted the LR preferences of the first account, and now the problem does not occur anymore. Strange. Either something was completely wrong with that preferences file, or some specific setting caused this.

Update 3: Ok, now it gets very strange: I found the culprit while systematically comparing the old and new prefs files: It is the currently active softproof profile [sic] of the image, even if the softproof itself is not active. With standard profiles like sRGB or AdobeRGB, everything is ok. However, using a printer profile such as "Canon iP4500/MP10 series PR2" causes the effect to appear. And it does so for raws (it was pure coincidence that the raw's proof was set to sRGB before). Update 3a: It seems to happen for all profiles that support perceptive rendering intend. Note: If an image does not have an explicitely assigned proof profile, it seems to default to the last used one - so if that was a profile with perceptive rendering, the effect appears for all images w/o an assigned softproof profile.
Photo of LRuserXY


  • 426 Posts
  • 41 Reply Likes

Posted 7 years ago

  • 1
Photo of Dorin Nicolaescu-Musteață

Dorin Nicolaescu-Musteață, Champion

  • 703 Posts
  • 38 Reply Likes

I have noticed this same behaviour with Develop shortcuts (+/–) when used with the Shift modifier.

EDIT: And yes, I happened to have used printer profile with perceptual intent last time in Soft proof.