P: Refreshing crop view on secondary display

@dw24154351 that fixed it! I'm still kind of amazed that this was a problem. Sounds like a Classic example (pun intended) of trying to fix something that wasn't broke. Many thanks.

11.4.1 seemed to solve some of the performance delay issues for thumbnail rendering.

The work around that seems to help the secondary display update more reliably is to have the Develop Navigator opened and visible.

"Any suggestions?"

Adobe has marked this bug as "Investigating".  Meanwhile, the only known workaround is to roll back to LR 11.2.

Mac OS Montery.

I use a primary and secondary display. Previously, when I was cropping on the primary display, the secondary display would show the resultant crop as I made it. Now, however, it does not. The cropping on the secondary display stays the same unless I start a new crop or close the cropping tool.

Any suggestions?

Re the thumbnails not updating to match the current crop, that's a known bug acknowledged by Adobe:

https://community.adobe.com/t5/lightroom-classic-bugs/p-library-previews-not-updating/idi-p/12897363

Rolling back to 11.2 is the only known workaround, which works for most people.

What's even more bizarre (now that I'm watching more carefully). The bottom thumbnail can finally render to match the main display but then after a short period, it re-renders an older crop. So it comes into sync but then goes back to be out of sync.

When you scroll the thumbnails at the bottom, the images being cached out of view are not up to date either.

You can make some updates and check and wait for them to correct.

Then scroll so that image goes out of view and then bring it back to the centre.

The thumbnail is showing an older crop. After a second or so, it renders the new crop.

So again, something is out of sync with the thumbnails. Once updated, the older thumbails should be discarded from the cache. In the current version, somehow the older images are being use and an update is being re-rendered.

May 2022 Update. The scenario is editing headshots which need consistency.

Cropping in the main display. Looking at both the secondary display and the thumbnails down below.

As you make the crop, the secondary display may or may not follow. It definitely isn't live, there is an irregular time delay whilst the secondary screen renders. What is really strange is that if you click off the current photo and then back, the secondary display is intially showing a crop from slightly before then after a second shows the current crop. Click off and back again and it does the same thing. It's as if two crops are being used, not just the latest. It's actually annoying that it's effectively "animating" your crops.

There is a random time delay for the bottom thumbnail crop to update. It isn't in sync with the secondary display either. The bottom display gives you a pretty good comparison between images, so you can eye ball the distance between the top of head and top of frame. So getting this right is important. The lack of live update is cumbersome.

There are no other processes going on at this point based on the progress in the top left. So there really doesn't seem to be an excuse for scheduling the rendering so late on both the thumbnail and the secondary screen. Sure the original raw is big, but there should be some memory optimisation of the screen and thumbnail - especially if the crop adjustment is slight.

The pattern of the crop interaction is to initially pick a reasonable crop which might be 70-80% of the image, then you are panning the image and then slightly adjusting the corners. So rendering could be optimised to not have to regen from the master each time you adjust the crop.

11.3.1

I just posted a comment to the thread describing an anomaly on the bug.  Making the image larger seems to work regardless of the navigator window.  Sometimes things like this will help the developers.  I used to be a developer.  Every little quirk can help track down a problem.

Thank you

Same crop delay bug but I noticed something interesting.  If I hide the navigator window and crop an image smaller, the bug appears and the second display is not refreshed.  If I expand the image crop area, the second display will immediately refresh.  If I continue dragging larger, the second display may or may not continue to update the second display.  It seems to be tied to how smoothly I move the handle.  If I release and start to go larger again, it immediately refreshes the second monitor.

I know this won't help anyone working around the problem, but sometimes data like this can help the developers track down a problem more easily.