Display Runtime: Ctrl+Mousewheel to adjust zoom

[tanviash]

Ctrl+ scroll mousewheel down on an opi file zooms out the element but Ctrl + scroll mousewheel up does not zoom in the element.

[kasemir]

Works for me, testing in both the runtime and the editor.

Note that you need to be on the 'background' for general Ctrl+mousewheel zoom in/out.
If the mouse is inside a plot, it'll instead zoom the axis etc., whatever is under the mouse.

[tanviash]

Not for plots. In general, if I have an opi/bob file open and I want to zoom in anywhere on the opi file with mousewheel, that doesn't work.

[kasemir]

Well, cannot reproduce. Works fine, actually even better since #1119 where Pavel fixed the synchronization of the mousewheel zoom with the zoom drop-down in the toolbar.

[pavel-ch]

I must admit I have observed this behavior on a CentOS 7 system. One wheel direction works, the second not, not only for zoom but even for Scroll Bars.
On Windows, this works for me as expected. Both systems were installed with the same Phoebus and Java 11 versions. So I think this must be somewhere in between Java and X11. I did not investigate that because I do not use this CentOS in production. Maybe needs further digging.

[pavel-ch]

Update:
Tested now with that CentOS 7. Scroll bars work well (maybe after an update?).
Zoom is showing the above described behavior.
As I am not an expert in Linux and X11 I can only give the configuration to find a common point:

From Phoebu/info:
java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 11+28
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 11
java.vendor = Oracle Corporation
java.vendor.url = http://java.oracle.com/
java.vendor.url.bug = http://bugreport.java.com/bugreport/
java.vendor.version = 18.9
java.version = 11
java.version.date = 2018-09-25
java.vm.compressedOopsMode = 32-bit
java.vm.info = mixed mode
java.vm.name = OpenJDK 64-Bit Server VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 11
java.vm.vendor = Oracle Corporation
java.vm.version = 11+28
javafx.runtime.version = 13.0.1+1
javafx.version = 13.0.1

uname -a:
Linux xxx 3.10.0-1062.9.1.el7.x86_64 #1 SMP Fri Dec 6 15:49:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

rpm -qa |grep xorg-x11-server-Xorg:
xorg-x11-server-Xorg-1.20.4-7.el7.x86_64

rpm -qa |grep xorg*:
xorg-x11-fonts-Type1-7.5-9.el7.noarch
xorg-x11-drv-intel-2.99.917-28.20180530.el7.x86_64
xorg-x11-proto-devel-2018.4-1.el7.noarch
xorg-x11-drv-nouveau-1.0.15-1.el7.x86_64
xorg-x11-drv-evdev-2.10.6-1.el7.x86_64
xorg-x11-xauth-1.0.9-1.el7.x86_64
xorg-x11-drivers-7.7-6.el7.x86_64
xorg-x11-utils-7.5-23.el7.x86_64
xorg-x11-drv-void-1.4.1-2.el7.1.x86_64
xorg-x11-drv-vmware-13.2.1-1.el7.1.x86_64
xorg-x11-server-utils-7.7-20.el7.x86_64
xorg-x11-font-utils-7.5-21.el7.x86_64
xorg-x11-xinit-1.3.4-2.el7.x86_64
xorg-x11-drv-ati-19.0.1-3.el7_7.x86_64
xorg-x11-server-common-1.20.4-7.el7.x86_64
xorg-x11-drv-qxl-0.1.5-5.el7.x86_64
xorg-x11-drv-synaptics-1.9.0-2.el7.x86_64
xorg-x11-xkb-utils-7.7-14.el7.x86_64
xorg-x11-server-Xorg-1.20.4-7.el7.x86_64
abrt-addon-xorg-2.1.11-55.el7.centos.x86_64
xorg-x11-drv-fbdev-0.5.0-1.el7.x86_64
xorg-x11-drv-wacom-0.36.1-3.el7.x86_64
xorg-x11-drv-v4l-0.2.0-49.el7.x86_64
xorg-x11-drv-vmmouse-13.1.0-1.el7.1.x86_64
xorg-x11-drv-dummy-0.3.7-1.el7.1.x86_64
xorg-x11-drv-vesa-2.4.0-3.el7.x86_64

[kasemir]

Well, some ideas to check for those who see the problem:

Is the problem limited to our code, or does it show up in other X apps?
Does the mousewheel work both ways in a GNOME terminal window where plain scrollwheel should scroll the text up/down?
Does the mousewheel work both ways in Firefox where Ctrl-scrollwheel should zoom in/out?

In our code, we hook to the scrollwheel in JFXRepresentation around line 270:

if (isEditMode())
    model_root.addEventFilter(ScrollEvent.ANY, evt ->
    {
        if (evt.isShortcutDown())
        {
            evt.consume();
            doWheelZoom(evt.getDeltaY(), evt.getX(), evt.getY());
        }
    });
else
    widget_parent.addEventHandler(ScrollEvent.ANY, evt ->
    {
        if (evt.isShortcutDown())
        {
            evt.consume();
            ScrollEvent gevt = evt.copyFor(model_root, scroll_body);
            doWheelZoom(evt.getDeltaY(), gevt.getX(), gevt.getY());
        }
    });

In edit mode, we capture every scroll event ('filter') at a higher level, while in runtime mode we allow events reach other widgets like the plots.
Do you see a difference in edit vs. runtime mode?
Do you see a difference when changing ScrollEvent.ANY into ScrollEvent.SCROLL?

[tanviash]

@kasemir I'm running Phoebus on Debian 10. Building and running Phoebus locally.
Mousewheel works correctly both ways in Firefox where Ctrl-scrollwheel is zooming in/out. Mousewheel works both ways in a GNOME terminal window where plain scrollwheel scrolls the text up/down.
Both runtime and edit shows the same problem with ctrl+mousewheel scroll.
I changed ScrollEvent.ANY into ScrollEvent.SCROLL and built and ran Phoebus but the problem did not resolve.

Here are few more test scenarios I performed.
If I use "ssh -X" to remotely log onto a machine (which is Debian 10) and run Phoebus, same problem is seen.
However, if I use x2go client to remotely log on to same Debian 10 machine and run Phoebus, problem is not seen.

Phoebus/info

java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 11.0.6+10-post-Debian-1deb10u1
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 11
java.vendor = Debian
java.vendor.url = https://tracker.debian.org/openjdk-11
java.vendor.url.bug = https://bugs.debian.org/openjdk-11
java.version = 11.0.6
java.version.date = 2020-01-14
java.vm.compressedOopsMode = Zero based
java.vm.info = mixed mode, sharing
java.vm.name = OpenJDK 64-Bit Server VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 11
java.vm.vendor = Debian
java.vm.version = 11.0.6+10-post-Debian-1deb10u1
javafx.runtime.version = 13.0.1+1
javafx.version = 13.0.1

[pavel-ch]

Remark: running with -Dprism.order=sw due to memory leaks, but no change without that

[kasemir]

On your Linux desktop, do you have a find-the-mouse feature enabled, something where pressing Ctrl makes the mouse pointer larger or somehow helps find it?
We've had that conflict with CS-Studio: You could no longer Ctrl-C copy stuff, because Ctrl enabled that find-the-mouse feature, took the focus from the widget, and then nothing got copied.

[kasemir]

running with -Dprism.order=sw due to memory leaks

Real leaks?
I see VIRT memory explode unless setting export MALLOC_ARENA_MAX=4

[tanviash]

find-the-mouse feature

Find-the-mouse feature is not enabled. Also, Debian 10 uses wayland display server.
env | grep XDG_SESSION_TYPE
XDG_SESSION_TYPE=wayland

[pavel-ch]

running with -Dprism.order=sw due to memory leaks

Real leaks?
I see VIRT memory explode unless setting export MALLOC_ARENA_MAX=4

On that CentOS 7, I experienced a Phoebus UI reaction slowdown through time (days) and heap growth. With -Dprism.order=sw this disappeared.
It was just a googled solution, no expertise from my side.