RFC: How should darkroom zooming-in behave?

[jenshannoschwalm]

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

There has lately been some work on darkroom zooming and touchpad gestures by @da-phil and @masterpiga and that's good as users having a touchpad need/want better support for that in dt.

But i definitely expect to stop zooming in at the fixed levels with "normal" mouse scrollwheels. We can override these fixed levels by combining with CTRL already).

After #21011 i zoom in "freely" and that's a clear regression to me.

Steps to reproduce

Open any image in darkroom and zoom-in by using a mouse scrollwheel (or by using the two-finger thingy - i simply forgot how that is called correctly :-)

Expected behavior

Stop zooming in at fixed 100% and 200% levels

Logfile | Screenshot | Screencast

No response

Commit

b04e36e

Where did you obtain darktable from?

self compiled

darktable version

master at 0e3b875

What OS are you using?

Linux

What is the version of your OS?

Fedora 44

Describe your system

nothing noteworthy

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

doesn't matter

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

doesn't matter

[da-phil]

Oh, didn't notice that we can happily scroll all the way to 1600% again ;)

As mentioned in my previous PR which also got merged, I actually prefer this behaviour as I do not need another helper key (CTRL) to be able to zoom in >100%, it is overall more convenient for me, in all three cases:

• scrolling with the mouse wheel
• scroll zoom gesture
• pinch-zoom gesture

But I also do not mind if we keep the old behaviour of having a hard limit at 100% and needing an additional key to zoom beyond this artificial limit, because I do not need to zoom in >100% frequently.

It's interesting though that after my last commit - which restored the old behavior upon @jenshannoschwalm's request - @masterpiga was able to activate this behavior in his PR further down the call-sequence. There must be a logic flaw in the code now, as the constrain flag within dt_dev_zoom_move() should exactly enforce such a hard limit, right?

[jenshannoschwalm]

That's why i opened a "RFC" to discuss this with all interested users & devs :-)

For me the "free zooming" is absolutely annoying when using dt developing images. When using the mouse i zoom-in at that position, do something, and can again zoom-out to that position. That's very difficult to do with my notebook touchpad so a) i always attach a mouse because that's much faster or b) use my midi device for zooming and c) only use the touchpad if nothing else is available.

How often do i want to zoom in more than 100%? very rarely!
How often to 200%? Almost never - can't remember doing so.
(I only do/did that when actively developing code or checking issue on photosite or pixel level.)

[gi-man]

I dislike free zooming when working with a mouse. I don't use a touchpad with dt, so no opinion with that interface.

[wpferguson]

How often do i want to zoom in more than 100%? very rarely!
How often to 200%? Almost never
(I only do/did that when actively developing code or checking issue on photosite or pixel level.)

Exactly how I use it, though I can remember going to 200% in a couple of cases 😄

[da-phil]

The question is: can we also change the behavior via a config param, which activates the 100% limit by default and let's other users go beyond 100% (without additional keyboard involvement) if they like this behavior more?

[jenshannoschwalm]

How often do i want to zoom in more than 100%? very rarely!
How often to 200%? Almost never
(I only do/did that when actively developing code or checking issue on photosite or pixel level.)

Exactly how I use it, though I can remember going to 200% in a couple of cases 😄

Pixelpeeper!

[da-phil]

I created a PR which re-activates the 100% zoom limit, with a config option to disable the limit:
#21031

[masterpiga]

I don't feel strongly one way or another. Initially I found the limit at 100% annoying, but then I got used to it and it does not bother me anymore.

From a UX and discoverability perspective, the limit is problematic because it is not obvious. You try to zoom in and you can't, and the reason why it is like that is not obvious. At the same time, it is nice to have a way to quickly zoom to 100% or fit-to-screen without having to modulate the scroll speed too exactly.

Maybe the best of both worlds would be to have some kind of "inertia" when passing those zoom levels. I.e., the zoom would naturally stop at 100%/fit, but then scrolling again in the same direction would go past the limits. I don't know whether this option has been considered already and discarded.

[da-phil]

I don't feel strongly one way or another. Initially I found the limit at 100% annoying, but then I got used to it and it does not bother me anymore.

From a UX and discoverability perspective, the limit is problematic because it is not obvious. You try to zoom in and you can't, and the reason why it is like that is not obvious. At the same time, it is nice to have a way to quickly zoom to 100% or fit-to-screen without having to modulate the scroll speed too exactly.

After doing a little bit of git history forensics and looking at the original code by @dterrahe,
I understood that the constrained switches between soft limits and hard limits, not "cap at 100%". The hard ceiling is 16× (= 1600%), the hard floor is tscalefloor.
So the original semantic was: "constrain" = "CTRL is NOT held". The flag was the user's "stop snapping me to named zoom levels" escape hatch, and CTRL was the bypass.

What the soft limits in _calculate_new_scroll_zoom_tscale() actually do per scroll step (when constrained == TRUE):

  ┌───────────────────────┬───────────────────────┬────────────────────────┐
  │         state         │ zooming in: capped at │ zooming out: capped at │
  ├───────────────────────┼───────────────────────┼────────────────────────┤
  │ tscaleold < fit       │ 1.0 (100%)            │ tscalefloor            │
  ├───────────────────────┼───────────────────────┼────────────────────────┤
  │ fit ≤ tscaleold < 1.0 │ 1.0                   │ fit                    │
  ├───────────────────────┼───────────────────────┼────────────────────────┤
  │ 1.0 ≤ tscaleold < 2.0 │ 2.0                   │ fit                    │
  ├───────────────────────┼───────────────────────┼────────────────────────┤
  │ tscaleold ≥ 2.0       │ 16.0 (= hard ceiling) │ fit                    │
  └───────────────────────┴───────────────────────┴────────────────────────┘

So each scroll step gets capped at the next canonical stop (fit / 100% / 200%), but once you're past 200% the cap evaporates and you can scroll all the way to 1600%.

In my opinion this is a strange and non-obvious UX design and agree with @masterpiga. I have not seen any other (image editing) software which operates in a similar way, also it unnecessarily overcomplicates the software logic in _calculate_new_scroll_zoom_tscale().

If we all agree that having only the hard "screen fit" and 100% limits, and pressing CTRL while zooming is lifting this limit entirely is all we need, then this would already improve and simplify the logic.

For DT_ZOOM_1 cycling (the middle-button toggle), clicks switch between "cycle through screen fit ↔ 100% ↔ 200%" vs "always go to 1:1", which IMHO is a reasonable and obvious action, which can stay as is. Maybe add another canonical stop (e.g. 400 or 800) then I might even further reduce the necessity for the "zooming beyond 100% while scrolling" feature.

Maybe the best of both worlds would be to have some kind of "inertia" when passing those zoom levels. I.e., the zoom would naturally stop at 100%/fit, but then scrolling again in the same direction would go past the limits. I don't know whether this option has been considered already and discarded.

I also thought about that, but this seems again like something that might overcomplicate the logic, hence I went for the binary config option to activate the 100% limit or lift it in my above linked draft PR.
But if the other group of people, who favor the 100% limit, could live with such a functionality to prevent accidental "zooming beyond 100%", I would be also happy to look at this option, then we wouldn't need yet another config option.

[jenshannoschwalm]

Just mentioning, tried latest master with the 200% restriction in preferences. Does not work for me.

BTW i don`t agree about the 100% / 200% restrictions being bad UI.

[masterpiga]

BTW i don`t agree about the 100% / 200% restrictions being bad UI.

It is not the restriction that is bad (problematic, in my words). It's the fact that the interface does not make it obvious that the restriction can be overridden, and how. The inertia suggestion above would make the mechanism discoverable without voiding the restriction, and without adding a configuration option.