Rawtherapee: Using mouse wheel to zoom in sometimes zooms out.

[heckflosse]

This is caused by getting a GDK_SCROLL_SMOOTH with deltaX == deltaY == 0.0.
In this case we don't know the direction the mousewheel was turned and in past assumed 'Downwards'.

Suggested fix: Do nothing in this case:

diff --git a/rtgui/cropwindow.cc b/rtgui/cropwindow.cc
index 45372f1f5..6eac5e59d 100644
--- a/rtgui/cropwindow.cc
+++ b/rtgui/cropwindow.cc
@@ -275,6 +275,10 @@ void CropWindow::scroll (int state, GdkScrollDirection direction, int x, int y,
     } else {
         delta = deltaY;
     }
+    if (delta == 0.0 && direction == GDK_SCROLL_SMOOTH) {
+        // sometimes this case happens. To avoid zooming into the wrong direction in this case, we just do nothing
+        return;
+    }
     bool isUp = direction == GDK_SCROLL_UP || (direction == GDK_SCROLL_SMOOTH && delta < 0.0);
     if ((state & GDK_CONTROL_MASK) && onArea(ColorPicker, x, y)) {
         // resizing a color picker

[Beep6581]

To reproduce:

1. Open image in Editor.
2. Once everything has loaded, move the scroll-wheel one notch to zoom in. RT zooms out.

Fix confirmed.

[ff2000]

I have the same issue in the file browser: Scrolling down sometimes scrolls up. Can the same patch be applied there?
I regularly get an unworkable state where not just the first scroll event goes in the wrong direction but also subsequent ones, so the file browser always scrolls up and the editor zooms out forever.
I think this is caused by gtk+ (3.24.1 here on Gentoo Linux). Do you know if there is an upstream issue report?

[heckflosse]

@ff2000

Can you try this patch please?

diff --git a/rtgui/thumbbrowserbase.cc b/rtgui/thumbbrowserbase.cc
index fdb551f45..5f75967e6 100644
--- a/rtgui/thumbbrowserbase.cc
+++ b/rtgui/thumbbrowserbase.cc
@@ -76,6 +76,10 @@ void ThumbBrowserBase::scroll (int direction, double deltaX, double deltaY)
     } else {
         delta = deltaY;
     }
+    if (direction == GDK_SCROLL_SMOOTH && delta == 0.0) {
+        // sometimes this case happens. To avoid scrolling the wrong direction in this case, we just do nothing
+        return;
+    }
     double coef = direction == GDK_SCROLL_DOWN || (direction == GDK_SCROLL_SMOOTH && delta > 0.0) ? +1.0 : -1.0;

     // GUI already acquired when here

At least it should avoid scrolling the wrong direction...

[heckflosse]

@ff2000 I can reproduce this issue only on my laptop running Sabayon. Are you on a laptop as well?

[ff2000]

Thx, the patch fixes the issue.
I can reproduce this on both a Laptop (with a normal desktop-mouse plugged in) and a desktop machine. As Sabayon is Gentoo-based this might be a Gentoo-issue...

[heckflosse]

@Beep6581 As you could reproduce the issue, was that also on a Sabayon/Gentoo system?

[heckflosse]

Imho the patch is save to push. I will do that now, but keep the issue open.

[Beep6581]

@heckflosse I never experienced what was described here https://github.com/Beep6581/RawTherapee/issues/5036#issuecomment-442165022

@ff2000 could you explain to me exactly how to reproduce?

[ff2000]

@Beep6581 The general case is the same as in the editor: Scroll the wheel one tack down and it won't scroll down but up. Turning the wheel down several steps in one go will still scroll up for the very first event but all the others will scroll down. This was always reproducible.

The other thing I mentioned wasn't reproducible in a specific way and it didn't happen every day. It just happened in the middle of a session that EVERY TIME I turn the wheel down - especially for a multi-step turn - it would always result in scrolling up (filebrowser) or zooming out (editor). In that case restarting RT was the only thing I could do. I am curious how this case will end up with the two patches from this issue.

[heckflosse]

Ok to close?

[ff2000]

I think it can be closed. I don't know GTK+ enough but I think it shouldn't post such events in the first place. I also didn't experience an issue since the patches.