[Bug] extreme mousewheel sensitivity when zooming

[thirstyone]

System

UVtools v5.0.5 X64
Operative system: Linux Mint 22 X64
Processor: Intel(R) Core(TM) i7-2675QM CPU @ 2.20GHz
Processor cores: 8
Memory RAM: 15.11 / 15.53 GB
Runtime: linux-x64
Framework: .NET 9.0.0
AvaloniaUI: 11.2.3
OpenCV: 4.9.0

Sreens, resolution, working area, usable area:
1: 1440 x 900 @ 100% (On this)
    WA: 1440 x 867    UA: 1440 x 867

Path:       /tmp/.mount_UVtooluVFCpK/usr/bin/
Executable: /tmp/.mount_UVtooluVFCpK/usr/bin/UVtools
Loaded file: espdashtry2 (5.0.5, inverted).svgx [Version: 0] [Class: FlashForgeSVGXFile]

Printer and Slicer

• Printer:
• Slicer:

Description of the bug

I'm using UVtools for pcb exposure. It's way too difficult to zoom in to a needed level with the mousewheel - it's either too big or too small, and it takes quite an effort to get into the right zoom level. Is there a way to make the mousewheel less sensitive?

How to reproduce

open any pcb, try to zoom in/out

Files

No response

[sn4k3]

Each zoom tick will increase zoom by 0.25x / 0.5x / 1x / 4x depending on your current zoom level.
Zoom sensibility comes from mouse (If you use a free scroll well style or a special software controlled mouse) and from system. Program just catch each tick event... A tick is when you fell the mouse wheel to "click" in each movement.

For me under linux I can easy use zoom with precision to whatever level.
This is either your mouse or system settings

[thirstyone]

Indeed, I tried it on another linux mint system, with a real mouse, and it worked just fine. I connected that mouse to my initial system - and it also worked fine. So, the problem is narrowed down to my touchpad (I use the same two-finger 'scroll' gesture to zoom in and out, that I use to scroll content in browsers). However, there are couple of points:

1. this gesture works just fine with other software (e.g. kicad, system interface) - the problem is just with UVtools.
2. i couldn't find anything related to trackpad in this regard in system settings.

so, may be, it has something to do with the underlying framework?

[sn4k3]

Today I tried on my laptop, and it work good with trackpad, on Windows. I also tested on Mint under a VM and work as same as the windows version.
I guess this is related to the sensitivity of the gesture

[mnemnion]

+1, trying to scroll using the stock touchpad on macOS is unusable, the slightest gesture scrolls by many levels and I have been unable to get it to scroll incrementally no matter how delicately I try.

Adjusting the system-level sensitivity is not an acceptable fix here, the touchpad works correctly with every other program I use so I won't sacrifice that to make UVTools usable.

What would plausibly work is making the number of 'ticks' per zoom level itself configurable. The problem might also be with the framework, or how it's configured for macOS builds, none of that is clear to me.

I don't intend to come across as demanding or ungrateful, it's just a bug after all. I want to make it clear that the current behavior makes scrolling out to get context on islands impossible using my touchpad, and that affects my ability to use UVTools to detect and support islands. I don't have any modifications to how the operating system interprets the scroll gesture, so it seems plausible that anyone using a Mac touchpad is going to find things similarly unusable.

I wasn't able to find keystrokes to effect the change in zoom level, or UI controls for it other than scrolling itself. If there's a way to do it by pressing keys, I would prefer that anyway, so if anyone knows how to do that, it would be a useful thing to add to this issue while it remains open.

[sn4k3]

The problem is that I have nowhere to test this to come to a proper solution. I have a clue of the problem which is: The touch pad zoom is active sending zoom events each minor movement, this is processed by framework and we have no way to configure. UVtools zoom out or in each time the event triggers.

Try to replace this file in your application contents and report back (I have implemented a 20ms debounce for scroll) and also included Meta + and Meta - to zoom in/out

UVtools.AvaloniaControls.zip

[mnemnion]

This is so much better, that was a good idea! It's still slightly 'zippy', the ideal number might be 25ms or 30? But as-is it's quite usable, thanks.

The keyboard zoom is great, just a note that it took me a second to find it because the mapping translates to Command + / -, not Option, which is the more expected Meta; Command in Linux terms is usually Super. Command + / - is idiomatic for zoom in and out on macOS, so it's the ideal choice, I'm mentioning that as a documentation thing.

I'm happy to report back about a 25 and 30 ms version of the debounce, if you'd like to build them. I don't think the response would vary much, or at all, based on the specific model of Mac.

[sn4k3]

Here the 30ms version: UVtools.AvaloniaControls_30ms.zip

[mnemnion]

It might be worth trying 40, this edition moves one to three levels with a small gesture, but it's tricky to get just one at a time. That's enough delay to make the interface easy to use, the fully dialed-in debounce might be just that smidgen slower.

I checked with a trackball scroll wheel as well and it works great with that instrument.

[sn4k3]

You can keep adding time without negative effect up to the image redraw time. Each zoom needs to redraw the image region and that take a little time based on image resolution. However, with 50ms I already notice a non-fluid scroll on my Windows if I spam the scroll wheel, which does not feel natural to me. The truth is that UVtools was not made with laptop's in mind.

UVtools.AvaloniaControls_40ms.zip
UVtools.AvaloniaControls_50ms.zip

[mnemnion]

40ms is an improvement on 30ms, and if it doesn't have negative consequences for other inputs (at least on my trackball scroll wheel it's just fine), I'd say that's the one to go with. I didn't test 50 because you indicated it was affecting other devices, so it can't really be the global optimum.

There's no reason to prioritize being able to reliably get one level of zoom change at a time with a Mac trackpad, especially with Meta/Cmd + and - added for doing exactly that. At 40ms it's quite controllable, in that I can scroll in and out without losing the island, so from my perspective that's a complete fix.

Thanks for taking the time to address this.

[sn4k3]

Try this file, I've disable normal event and subscribe only to a touchpad gesture. Also I removed the debounce to see how it works.
Additionally it will create a file on your desktop, do some zoom in/out and report the findings plus the txt file contens

UVtools.AvaloniaControls_touchpadonly.zip

[thirstyone]

Hey, thank you for your effort!
The last one didn't work at all. I tried the 40ms version, and it seems to have solved my problem.
Now, I wonder if I have to stick to my current version or to manually update the file with each new version of the app.

[mnemnion]

Can confirm, the touchpadonly iteration broke scrolling: with a trackpad, using Cmd-+/-, and with a trackball scrollwheel.

Here's the log:

UVtools_Scroll.txt

[sn4k3]

Ok, so TouchpadGesture not working here.
BTW can you try the gesture to move horizontal scroll bar on touchpad? My guess is that wont work.

Also your txt give me the final clue. The reason why current implementation is zooming crazy is because your increments are very tiny, you have deltas of 0.02 and 0.01, and the code ignore delta value because it uses Ticks instead of real zoom. So each time event fires it increate a tick which in mouse wheel deltas are 1.0.
I will try a new patch to see the result...