scrolling behaviour difference between gtk2/gtk3

[Thomas Pointhuber]

# Current Behaviour

https://cloud.oe5tpo.com/s/78PCaiP8N4BxkDn (please note, between every scroll step I waited for a short time. Especially in the gtk3 video it looks like I did multiple steps, but actually this was only one)

## GTK2 (WX3.1):

scroll in/out works most times in equal steps. But sometimes (2 steps in, 2 steps out, 2 steps in) it comes out with a different view. (Warp on Cursor disabled). In my case, look at one edge, don't move the mouse but do multiple scroll steps in and out repeatedly (same amount). Sometimes the zoom changes (additional step/half step), but actually, this shouldn't happen. It should work consistently.

## GTK3 (WX3.0):

it simply looks like multiple scroll events are processed

# Expected Behaviour

Zoom steps are reproducible and no weird changes occur. My mouse has no defect, as tested because firefox, for example, behaves correctly and reproducible when scrolling.

# System Information:

Application: pcbnew
Version: (6.0.0-rc1-dev-291-g78ab5c3f0), debug build
Libraries:

[Nick Østergaard (nickoe)]

Is wxpython enabled?

[Thomas Pointhuber (pointhi)]

Interesting. Version Info shows WX_PYTHON decativated:

Application: pcbnew
Version: (6.0.0-rc1-dev-291-g78ab5c3f0), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.4) nghttp2/1.32.0
Platform: Linux 4.17.12-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
    Boost: 1.67.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.0
    Compiler: Clang 6.0.1 with C++ ABI 1002

Build settings:
    USE_WX_GRAPHICS_CONTEXT=ON
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

but on the command line the following appears:

/usr/lib/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py:16629: UserWarning: wxPython/wxWidgets release number mismatch
  warnings.warn("wxPython/wxWidgets release number mismatch")

[Wayne Stambaugh (stambaughw)]

wxWidgets built against gtk3 is currently not supported due to the huge number of issues. You must use wxWidgets built against gtk2. I believe most linux distros are distributing wxWidgets built against both gtk2 and gtk3.

[Maciej Suminski (orsonmmz)]

The release number mismatch message might be caused by a pcbnew Python plugin that imports 'wx' library.

[Thomas Pointhuber (pointhi)]

I did some debugging and found out that WX_VIEW_CONTROLS::onWheel get multiple events on a single scroll action.

GetWheelRotation() returns the same value nonetheless if only one or multiple events are thrown. Thish means it is not an issue that the rotation part is hardcoded at the moment (should be fixed to support higher resolution mics in the future, see: https://docs.wxwidgets.org/trunk/classwx_mouse_event.html#a0bb1e43dbaa5b1185cdff155e0edf1a2)

The issue only happens on the Accelerated GAL panel, not on the Fallback panel.

[Thomas Pointhuber (pointhi)]

I did some more testing:

The GTK2 bug is visible in Fallback as well. It is only visible on quick scrolling changes (One step in and out immediately). I assume the scroll display is not in fixed steps but has some sort of smoothing. Doing a zoom action the current board-area visible is used for calculations instead of the one the animation is aiming for. This causes zoom in/out to be not to reliable point to the same board.

The GTK3 bug, on the other hand, is only visible in case of accelerated graphics (which is pretty weird). I verified with xinput that no wrong events are coming from the mouse, as well as by using a cheap one for comparison. From those tests, I assume the hardware/software stack of the OS should behave correctly.

As previously said, WX_VIEW_CONTROLS::onWheel seems to get two events instead of one. When I focus a different window and then go back to pcbnew, only a single scroll event is emitted for the first scroll action, afterwards two events are emitted again.

I was able to mitigate the issue by enabling MAC behavior, as well as changing the dscale parameter to 0.001 instead of 0.01:
https://github.com/KiCad/kicad-source-mirror/blob/cbf74d69390293f177f0bcb182d7d6e17b4cfa74/common/view/wx_view_controls.cpp#L162

I did, both, the GTK2 and GTK3 build on wx3.1

[Maciej Suminski (orsonmmz)]

Can you check if the problem is mouse specific?

[Thomas Pointhuber (pointhi)]

@orsonmmz,

I tested it with different mouses

[John Beard (john-j-beard)]

I see this too in GTK+ on OpenGL GAL canvases.

[John Beard (john-j-beard)]

I had a look here but I still can't see why it happens. The overall issue is than in the OpenGL canvas on GTK3, you get *two* scroll events for each actual scroll:

* Event 1: Rotation is 120 -> zoom by ~10%, as expected
* Event 2: Same rotation, but within a very short space of time, so this is accelerated as a "fast scroll" -> zoom by much more.
* Total zoom is then more like 50% that 10%.

What should happen: only one zoom happens, and the total zoom factor is about 10% per scroll step.

This happens for both zoom in and out, but not for the first ever scroll.

From what I can tell:

* OPENGL_GAL::skipMouseEvent( wxMouseEvent& aEvent ) is called twice. Each time, the aEvent has the exact same timestamp and the same address, so I think it's the same event
* This is wxPostEvent'd to the listener (EDA_DRAW_FRAME_GAL)
* For each event a copy is made and:
    * WX_VIEW_CONTROLS::onWheel( wxMouseEvent& aEvent ), receives two copies (as it is the first listener). This is where the acceleration of the second one happens.
    * It's passed onto the tool framework by the EDA_DRAW_FRAME_GAL::OnEvent

What I can't see is why OPENGL_GAL gets two mouse events here but CAIRO_GAL only gets one - as far as I can tell, they each only register themselves once and then pass the event on to the EDA_DRAW_FRAME_GAL in the same way.

A workaround is to do what @pointhi suggests, but all this really does is not accelerate the second one rather than avoid having it in the first place.

[John Beard (john-j-beard)]

That's a typo: "WX_VIEW_CONTROLS::onWheel( wxMouseEvent& aEvent ), receives two copies" -> Remove "receives two copies".

It receives a single copy for each Post'ed event, so two in total.

[Seth Hillbrand (sethh)]

FWIW, I also see multiple paint events on GTK3 OpenGL that appear to be duplicates. My next step in tracing this is to compile wx locally to track the steps internally but that's a larger undertaking and I haven't set it up yet.

[John Beard (john-j-beard)]

As an aside, here is a patch to at least suppress the worst of the effects by using the non-accelerated version (this is a re-casting of @pointhi's patch for the new scrolling system). It is not a proper solution, but it makes GTK3 OpenGL useable for me.

[Seth Hillbrand (sethh)]

This behavior is extremely limiting when using gtk3. John's patch addresses the worst of it but we will need to handle this properly before 5.1

[Wayne Stambaugh (stambaughw)]

@Seth, I haven't had a chance to review John's patch yet. Should we merge it now and fix the remaining issues or just wait for a more complete fix?

[Seth Hillbrand (sethh)]

I've been digging a bit more through this.

GTK3 implements a new "SMOOTH_SCROLL" function. wxWidgets helpfully maps this onto the normal scroll but doesn't remove the normal SCROLL_UP/DOWN event. So it queues up two events, one for the SMOOTH_SCROLL that is mapped onto SCROLL_UP/DOWN and a second for the normal SCROLL. This only happens when the wx event handler is called before the GTK event handler, otherwise the event is listed as handled.

I can't see a good way of preventing these other that testing the timestamps as John mentions.

That said, I like John's patch as well as the accelerating zoom was always an annoyance. Testing seems to work well.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 4475c2008c5c316c42c5efa880a19dbebea12521
https://git.launchpad.net/kicad/patch/?id=4475c2008c5c316c42c5efa880a19dbebea12521

[Fabián Inostroza (fabianinostroza)]

I know it's a matter of preference but I found the zooming in GTK3 to be really slow (small steps) without acceleration, can the constant GTK3_SCALE be changed? I tried multiplying it by two and found it to work nice.

[Frank Severinsen (shack)]

I just got the new GTK3 nightly build, and experience the same thing as @Fabian.
It feels pretty slow compared to GTK2.
Could the zoom either be increased or perhaps add a multiplier setting somewhere

[Frank Severinsen (shack)]

This applies to Eeschema and PCBnew, but not in the 3Dviewer

[Seth Hillbrand (sethh)]

Let's open a new bug report for customizing the zoom function. That'll need to be v6 as it involves a string change.

[Wayne Stambaugh (stambaughw)]

This would definitely be useful. There is noticeable difference on my Linux systems in zoom acceleration behavior. Our current setting feels about right using my laptop touchpad but on my desktop with a mouse, it is too slow. We could add this to a 5.1 bug fix release rather than push it off until v6 if it's not too painful to cherry pick.

[Frank Severinsen (shack)]

Would a multiplier of some sort for GTK3 be accepted for 5.1?

[Seth Hillbrand (sethh)]

Hi Frank-

The problem is that different input devices will generate different event multiples. So touchpads typically produce smooth_scroll events, so they give twice as many events as mouse scroll wheels. If we put a multiple in for GTK3, we will get scrolling via mousepads that is much too fast.

[Fabián Inostroza (fabianinostroza)]

Hi Seth, is it just a difference between mouse and touchpad? How many people use touchpads for drawing schematics, pcb or any other kind of drawing?

@Frank I modified the file include/view/zoom_controller.h and multiplied the GTK3_SCALE by 2, works fine for me

[Seth Hillbrand (sethh)]

Unfortunately, it depends on the GDK backend (https://developer.gnome.org/gdk3/stable/gdk3-Event-Structures.html). Some do, some don't. All trackpads I've used generate these events. Not all mice I've used do. Some do and scrolling is normal in pcbnew. Some don't and it's slower.

We could set the multiple and then match duplicate timestamps as John suggested above. That would filter the smooth events. How bad is the effect? Is it worth a potentially jumpy implementation (if the timestamps don't arrive sequentially then we would miss the duplicates)?

[Seth Hillbrand (sethh)]

Hi Frank/Fabián-

I've pushed an update to handle this correctly. It turns out that we can disable the extra events through environmental variables. I've done that and doubled the multiple.

This has the added benefit of speeding up GTK3 back to GTK2 levels as we're not dealing with a bunch of extraneous events (really noticeable over remote connections)

Let me know if you see issues with this.

[Fabián Inostroza (fabianinostroza)]

Thanks Seth, works fine for me