Lightroom Classic interface slow on Windows

Lightroom Classic 15.4.1 on Windows: 1–2 second UI stalls when selecting photos — WPR trace points to MFC/Win32 window-handle processing

Hello,

  I am investigating a persistent Lightroom Classic performance problem on Windows. Selecting a different image can freeze the entire Lightroom interface for approximately 1–2 seconds.

  This does not appear to be caused by RAW decoding, storage performance, the catalog, previews, GPU acceleration, plug-ins, or monitor refresh technology. Windows Performance Recorder traces consistently point to Lightroom’s main UI thread spending substantial CPU time in MFC and Win32 window-handle processing.

  ## System configuration

  - Lightroom Classic 15.4.1
    Build: 202606201310-b9f148a4

  - Camera Raw 18.4
  - Windows 11 Business, build 26200.8737
  - AMD Ryzen 9 5950X, 16 cores / 32 threads
  - 32 GB RAM
  - NVIDIA GeForce RTX 2080 Ti, 11 GB VRAM
  - NVIDIA driver 591.86
  - Catalog stored on an NVMe SSD
  - 12 MP RAW files stored on another NVMe SSD
  - Approximate sequential performance of the drives: 3,500–7,000 MB/s
  - No Lightroom plug-ins installed

  Normal monitor configuration includes:

  - BenQ SW270C, 2560×1440 at 60 Hz — Lightroom display
  - ASUS PA278QV, 2560×1440
  - Acer AT2219/M220MF

  The BenQ SW270C is a fixed-refresh display without VRR. I also reproduced the problem after disconnecting the other displays and restarting Lightroom with only the BenQ connected.

  ## Symptoms

  The main symptom is a 1–2 second delay when changing the selected photo.

  It occurs:

  - In Library Grid view
  - In Develop
  - In other Lightroom modules
  - With the mouse
  - With the keyboard arrow keys
  - With panels visible or hidden

  The whole Lightroom interface becomes unresponsive while the selection is being processed.

  A particularly noticeable mouse symptom is:

  1. I click a thumbnail.
  2. I immediately move the pointer to another thumbnail.
  3. Lightroom remains frozen.
  4. One or two seconds later, the selection action is finally processed.

  The delay is not always attached to one specific file. For example, image A may initially be fast and image B slow. After switching to B, both A and B may become slow. If Lightroom is left idle for some time, the next few selections may temporarily become immediate again.

  Develop/culling can feel even slower, but the same fundamental stall is reproducible in Library Grid view.

  ## Troubleshooting already performed

  I tested the following without resolving the problem:

  - Completely disabled GPU acceleration
  - Hid all Lightroom panels
  - Paused all Lightroom background activity
  - Created a new catalog
  - Reset Lightroom preferences
  - Confirmed that no plug-ins are installed
  - Removed and reinstalled the monitor ICC profiles
  - Disconnected the other monitors and restarted Lightroom with only the BenQ SW270C connected
  - Repeatedly switched among only three 12 MP RAW files so that previews and caches should already be warm

  Reinstalling the display profiles and using one monitor may have produced a small subjective improvement, but neither eliminated the stalls.

  A new catalog and fresh preferences made no meaningful difference.

  ## Process Monitor results

  I recorded the repeated switching among three images with Process Monitor.

  In a representative 10.35-second capture:

  - The sum of all captured filesystem-operation durations was approximately 14.34 ms.
  - The slowest individual filesystem operation was approximately 0.218 ms.
  - SQLite/catalog locking operations were measured in microseconds.

  There was no disk operation remotely close to the observed 1–2 second UI freezes.

  This strongly suggests that the application is not waiting for the catalog NVMe, RAW-file NVMe, Camera Raw cache, or antivirus file scanning during the stalls.

  ## Windows Performance Recorder results

  I recorded two WPR GeneralProfile traces.

  ### Original multi-monitor trace

  - Trace duration: approximately 63 seconds
  - Lightroom main UI thread CPU samples: 18,767
  - During the active switching period, the UI thread averaged approximately 696 samples per second
  - This corresponds to approximately 70% utilization of one logical CPU core
  - Peak: approximately 907 samples per second, or 91% of one logical core

  The UI thread was therefore actively consuming CPU, rather than waiting for disk I/O.

  ### BenQ-only benchmark

  For the second benchmark, I:

  1. Disconnected the other displays.
  2. Kept only the BenQ SW270C connected.
  3. Restarted Lightroom.
  4. Recorded a baseline interval.
  5. Performed 20 keyboard selection changes using the pattern Right, Right, Left, Left, repeated five times.

  Results:

  - Complete trace duration: approximately 78 seconds
  - No lost trace events
  - Baseline duration: 9.77 seconds
  - Baseline Lightroom UI-thread activity: approximately 0.83% of one logical core
  - Marked switching interval: 27.19 seconds
  - Lightroom UI-thread CPU time during that interval: approximately 10.68 seconds
  - During the dense switching section, the UI thread averaged approximately 60% of one logical core
  - Peak UI-thread utilization: approximately 84% of one logical core
  - Approximately 80% of Lightroom’s sampled CPU activity during the switching interval belonged to the main UI thread

  The different traces did not use exactly the same switching cadence, so the percentages should not be treated as a precise monitor-performance comparison. Nevertheless, using only one monitor produced at most a modest improvement and left the same stall and the same CPU hotspot intact.

  ## Repeated UI-thread hotspot

  Microsoft public symbols resolved the repeated hot path as:

  mfc140u!CMapPtrToPtr::GetValueAt
  mfc140u!CWnd::FromHandlePermanent
  mfc140u!CWnd::WalkPreTranslateTree
  mfc140u!AfxInternalPreTranslateMessage
  Lightroom main message loop

  In the BenQ-only switching interval, at least 807 UI-thread samples — approximately 7.6% of all sampled UI-thread CPU time — landed in the same
  CMapPtrToPtr::GetValueAt instruction cluster.

  Additional recurring Windows kernel hotspots resolved to:

  win32kfull!InternalBuildHwndList
  win32kfull!xxxWindowEvent
  win32kbase!ValidateHwndEx

  This indicates significant activity involving Windows window-handle lookup, validation, event processing, and HWND-list construction while Lightroom processes selection/input messages.

  ## Lightroom window/control enumeration

  I also enumerated Lightroom’s Win32 windows and child controls after the benchmark.

  Observed Lightroom process resources:

  - Approximately 4,030 USER objects
  - Approximately 914 GDI objects
  - 392 top-level HWNDs
  - 3,315 descendant HWNDs
  - Approximately 3,707 HWNDs in total

  The most interesting finding is the distribution of those controls:

  - Visible Library window tree: approximately 1,375 descendant controls
  - Hidden DevelopPanels window tree: approximately 1,829 descendant controls
  - Hidden secondary-display window: approximately 87 descendant controls

  The hidden DevelopPanels tree remained instantiated even while Library was the active module. It contained controls for items such as:

  - Navigator
  - Presets
  - Snapshots
  - History
  - Masks
  - Basic adjustments
  - Develop histogram
  - Sliders, edit fields, buttons, and other Develop controls

  Its approximate class composition included:

  - 1,016 AfxWnd controls
  - 378 static controls
  - 127 edit controls
  - 126 sliders
  - 120 buttons

  Therefore, hiding Lightroom panels does not appear to destroy these controls; it only makes them invisible.

  I do not know whether this number of HWND/USER objects is expected for Lightroom, but it appears directly relevant because the captured hotspot is MFC’s permanent HWND-to-CWnd mapping and Windows’ HWND validation/list-building code.

  ## Current interpretation

  The evidence is consistent with the following sequence:

  1. An image-selection input message reaches Lightroom’s main UI thread.
  2. Lightroom/MFC performs message preprocessing and permanent CWnd handle-map lookups.
  3. Windows performs additional HWND-list construction, validation, and window-event processing.
  4. Lightroom has several thousand instantiated Windows controls, including a large hidden Develop panel tree even when Library is active.
  5. The main UI thread consumes a substantial fraction of one logical core and the complete interface remains blocked until processing finishes.

  This would be consistent with:

  - Mouse and keyboard producing the same delay
  - The problem appearing in every Lightroom module
  - Hiding panels having no effect
  - A new catalog and new preferences having no effect
  - Fast NVMe storage having no effect
  - Warm previews/cache having no effect
  - Disabling the GPU having no effect
  - Disconnecting additional monitors providing only a minor improvement
  - Lightroom being idle between bursts sometimes temporarily improving responsiveness

  The trace does not provide Adobe’s private Lightroom function names, so I cannot identify the exact Lightroom source-level caller. Adobe symbols or internal instrumentation would be required for that. However, the public-symbol portion of the trace places the bottleneck in the Windows UI/message/
  handle path rather than in RAW decoding or filesystem access.

  I also did not find an obvious third-party DLL injected into the Lightroom process. A completely clean-boot comparison has not yet been performed, so interaction with an external Windows accessibility or event-hook application cannot be ruled out absolutely.

  ## Expected result

  Changing the selected thumbnail, especially among three already-viewed 12 MP images, should occur immediately and should not block the complete interface for 1–2 seconds.

  ## Questions for Adobe engineering

  1. Is it expected for Lightroom to instantiate approximately 3,700 HWNDs and more than 4,000 USER objects?
  2. Is the complete hidden Develop panel tree expected to remain instantiated while Library is active?
  3. Can Adobe reproduce high CPU usage in CWnd::FromHandlePermanent / CMapPtrToPtr::GetValueAt while changing the selected photo?
  4. Is this a known Windows-specific issue or a regression in Lightroom Classic 15.4.1?
  5. Could an Adobe engineer inspect the ETL using Lightroom’s private symbols?
  6. Is there an internal diagnostic build or logging option that can identify which Lightroom component is triggering the repeated HWND processing?

  I can provide:

  - The original multi-monitor ETL
  - The BenQ-only ETL with baseline and switching markers
  - Process Monitor CSV captures
  - Lightroom System Information
  - Exact thread IDs, marker timestamps, symbol offsets, and window-enumeration results

  The BenQ-only ETL is approximately 1.2 GB, so I would need an appropriate upload location.