Performance with zonemapper

[cycomanic]

Describe the bug

I've recently come back to lightzone after many years with other software (I still think lightzone has the most intuitive interface for making photo edits). However I've found that if I edit my photos and add a zonemapper module, lightzone slows to a crawl. In particular when zoomed in (I have a 4k monitor). Often the interface will freeze for 10s of seconds when zooming. If started from a terminal I will see lots of:

EventThread blocked for N.000 seconds

and also:

imer-0: TIMED_WAITING
        at java.base@21.0.8/java.lang.Object.wait0(Native Method)
        at java.base@21.0.8/java.lang.Object.wait(Object.java:366)
        at java.base@21.0.8/java.util.TimerThread.mainLoop(Timer.java:563)
        at java.base@21.0.8/java.util.TimerThread.run(Timer.java:516)
Thread-5: WAITING
        at java.base@21.0.8/jdk.internal.misc.Unsafe.park(Native Method)
        at java.base@21.0.8/java.util.concurrent.locks.LockSupport.park(LockSupport.java:371)
        at java.base@21.0.8/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(AbstractQueuedSynchronizer.java:519)
        at java.base@21.0.8/java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:3780)
        at java.base@21.0.8/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3725)
        at java.base@21.0.8/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1712)
        at java.base@21.0.8/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:535)
        at java.base@21.0.8/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1070)
        at java.base@21.0.8/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base@21.0.8/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base@21.0.8/java.lang.Thread.runWith(Thread.java:1596)
        at java.base@21.0.8/java.lang.Thread.run(Thread.java:1583)
Thread-15: WAITING
        at java.base@21.0.8/jdk.internal.misc.Unsafe.park(Native Method)
        at java.base@21.0.8/java.util.concurrent.locks.LockSupport.park(LockSupport.java:371)
        at java.base@21.0.8/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(AbstractQueuedSynchronizer.java:519)
        at java.base@21.0.8/java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:3780)
        at java.base@21.0.8/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3725)
        at java.base@21.0.8/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1712)
        at java.base@21.0.8/java.util.concurrent.PriorityBlockingQueue.take(PriorityBlockingQueue.java:535)
        at java.base@21.0.8/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1070)
        at java.base@21.0.8/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base@21.0.8/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
        at java.base@21.0.8/java.lang.Thread.runWith(Thread.java:1596)
        at java.base@21.0.8/java.lang.Thread.run(Thread.java:1583)
Image Task Queue: WAITING
        at java.base@21.0.8/java.lang.Object.wait0(Native Method)
        at java.base@21.0.8/java.lang.Object.wait(Object.java:366)
        at java.base@21.0.8/java.lang.Object.wait(Object.java:339)
        at app//com.lightcrafts.ui.browser.model.ImageTaskQueue.waitForNotify(ImageTaskQueue.java:137)
        at app//com.lightcrafts.ui.browser.model.ImageTaskQueue.run(ImageTaskQueue.java:101)
        at java.base@21.0.8/java.lang.Thread.runWith(Thread.java:1596)
        at java.base@21.0.8/java.lang.Thread.run(Thread.java:1583)
RawImageCache: WAITING
        at java.base@21.0.8/java.lang.Object.wait0(Native Method)
        at java.base@21.0.8/java.lang.Object.wait(Object.java:366)
        at java.base@21.0.8/java.lang.Object.wait(Object.java:339)
        at app//com.lightcrafts.image.types.RawImageCache.run(RawImageCache.java:123)
Finalizer: WAITING
        at java.base@21.0.8/java.lang.Object.wait0(Native Method)
        at java.base@21.0.8/java.lang.Object.wait(Object.java:366)
        at java.base@21.0.8/java.lang.Object.wait(Object.java:339)
        at java.base@21.0.8/java.lang.ref.NativeReferenceQueue.await(NativeReferenceQueue.java:48)
        at java.base@21.0.8/java.lang.ref.ReferenceQueue.remove0(ReferenceQueue.java:158)
        at java.base@21.0.8/java.lang.ref.NativeReferenceQueue.remove(NativeReferenceQueue.java:89)
        at java.base@21.0.8/java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:173)
ZoneFinder Histogrammer: BLOCKED
        at app//com.lightcrafts.model.ImageEditor.ZoneFinder$Segmenter.getNextView(ZoneFinder.java:341)
        at app//com.lightcrafts.model.ImageEditor.ZoneFinder$Segmenter.run(ZoneFinder.java:359)

To Reproduce
Steps to reproduce the behavior:

1. edit a Sony A7ii arw file
2. add a zonemapper tool
3. zoom into the image
4. change zones in zonemapper

Expected behavior
Photo preview updates reasonably fast

Screenshots

Desktop (please complete the following information):

• Version: Latest git
• OS: arch linux

Additional context
I've tried profiling using visualvm and see lots of time spend on lcms doTransform (but I'm by no means a java expert, so this might be a red herring).

[sfink16]

I'm not experiencing that behavior on my Ubuntu 24.04 desktop but I do not have a 4K monitor, instead a 1080P monitor. Is zonemapper the only tool used in your toolstack? I ask because I do notice that if I have 5 or 6 tools in my tool stack LZ can with 1:1 zoom, it can slow down significantly. When it slows down too much I try not to do 1:1 zooms. When it get real bad I quit LZ and come back in. It seems to be a cache issue, something LZ has struggled with for quite some time. I do set LZ to the highest level of memory my desktop allows, 8 mb. Another workaround I've used is to close all other application such as my Firefox and Thunderbird, sometimes helping the situation.

[cycomanic]

I'm setting to 16 Gb cache and yes only when using zonemapper. If I add the relight tool only things stay much faster.

[cycomanic]

OK some more information, this seems to be entirely related to the zones calculation done for the "minipreview".

If I set the top right "minipreview" to colormask or histogram things become faster again. I've had a brief look at the code, but I've never done java programming, so nothing obvious sticks out.

[cycomanic]

I had a free trial for idea AI tools, so I asked claude code how to improve the performance, please see pull request #368 . In my testing it dramatically improved interactive performance and I have not observed any issues yet.

However keep in mind that I have not programmed in java so the pull request should be reviewed critically.

As a side note, I'm generally an AI sceptic (in my field of expertise AI tools often give incorrect results), but I'm amazed that this came back with an answer that worked without any adjustments.

[sfink16]

I had a free trial for idea AI tools, so I asked claude code how to improve the performance, please see pull request #368 . In my testing it dramatically improved interactive performance and I have not observed any issues yet.

However keep in mind that I have not programmed in java so the pull request should be reviewed critically.

As a side note, I'm generally an AI sceptic (in my field of expertise AI tools often give incorrect results), but I'm amazed that this came back with an answer that worked without any adjustments.

Good work! I'm useless in coding anything today. The last coding I did was in COBOL on a mainframe back last century, LOL. I hope it works!

[cycomanic]

Here are two videos demonstrating the performance difference I see.

Without the patch:

without_patch.mp4

With the pull request:

with_patch.mp4