Fix horizontal scrolling with touchpad devices

[folays]

Description

Fix scroll-x on touchpad

The standalone imgui "demo" exhibit the faulty behavior.
Table & columns -> Advanced ; Open Options

• reduce item count to a few (~5), so the Table is not "full" y-wise and thus y-scrollbar disappear
• raise the inner width to go beyond the width so that x-scrollbar appear

You are now in a situation with a Table having x-scrollbar but not y-scrollbar.

You can of course easily recreate the same situation in homemade code. Just fill a Table with large lignes (number of columns), small number of items.

With a touchpad (at least on Mac), the x-scrollbar is 99% unusable.

The x-scrollbar can be moved left/right ONLY IF we very very carefully (and with difficulty) touch the touchpad so that the operating system only issue a +/- on the x-axis and 0 on the y-axis.

Because the Table is not interested for scroll-y, the event is being "bubbled up" to the parent window.
It mess with the code which would have taken interest in the x-scroll on behalf of the Table.

Expected behavior

I guess that when the user has a mouse with two scroll wheels, the users can easily choose to "scroll only on X and be neutral (0) on Y".

But I have a hard time figuring out any situation where an user would really wish to AT THE SAME TIME scrolling on two different widgets (parent and children).
I guess that the expected behavior are rather:

• scroll only on X and ignore the other axis
• scroll only on Y and ignore the other axis
• scroll both on X and Y (diagonally) but only if inside the same widget

FIX of the pull request

If children window has interest for scroll-x, the fix prevent bubbling scroll-y events and lock further wheeling events to parent window.

The code changes of the pull request are including 3 components ;
The first 2 changes below should not change the "logic" of the code, they are for readability only.
The 3 change below should fix the bug.

1) Simplify the 2 lines calculating const float: wheel_y and wheel_x.

The two artimethic operations are being factorized to their simpler form.
The results should be 100% the same than before, if I'm right, it's only some boolean arithmetics.

Those two calculations are also moved at the top of the diff, the patch needing those resuls early.

2) Replace a frequent calculus by its own boolean

I replaced:

• BEFORE : (window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs) everywhere
• AFTER : the bool noScroll in replacements

3) The bug fix

The patch aim to stop bubbling the event as soon as a widget has interest for either scroll-x or scroll-y.
If the widget has interest for only one of the two scrolling axes, the second one will be ignored, which is probably the better situation.

I do not pretend to have inside knowledge of the internal of imgui.
I think I still have respected the intention of the original code.

In the case where the widget has no interest for one of the two scrolling axes, I guess a flag could also be introduced which would enable/disable bubbling up the ignored event to the parent window.
But it would probably require to split the StartLockWheelingWindow subsystem for the two axes.

[ocornut]

Hello,

Thanks for reporting this. I initially misunderstood the issue on my first read but now I realize that the scrolling events being dispatched to two windows is indeed wrong. Will fix this :)

2. Replace a frequent calculus by its own boolean

The purpose of the test is to climb up the parent hierarchy until we are stopped by those flags. Your change locks the flags to the first immediately hovered window which seems like a very different behavior.

Don't worry about reworking/fixing it, we'll be looking at this very shortly (along with other mouse-wheel related changes). Thanks a lot!

[folays]

Hi, I have read recent discussions in #4559 ;

My most recent comment (of today) in #4559 should be read, before this one comment here.

My #3795 above contained three "proposals"/"fixes" :

1) "Simplify the 2 lines calculating const float: wheel_y and wheel_x"...

...You seem to already have figured out this, by "factoring" the "?:" operation and removed the duplicate "g.IO.MouseWheel" which occured at the version I then had.
-> Thus, my request is deprecated on this point.

2) "Replace a frequent calculus by its own boolean"...

...Which I think would still be relevant today, because I think it would really simplify readability of the code still exhibing the problem.

This proposal is to simply "sed" replacing, without changing applied "logic":

replace :

(window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs)

with its own boolean, like :

bool noScroll = 
(window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs);

(new-lined just so that you see that the boolean contained the same thing than the original code).
In the current "master" branch :

imgui/imgui.cpp

Lines 3871 to 3876 in 612b787

	if (wheel_y != 0.0f)
	{
	StartLockWheelingWindow(window);
	while ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.y == 0.0f) || ((window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))))
	window = window->ParentWindow;
	if (!(window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))

Applying this would really simplify the "readability" of the condition tested in the while Loop at line 3874.

I agree that my original proposal may have skip the fact that the "boolean evaluation" (evaluate the expression) should be eval'ed (set) at each run of the loop, so probably something like:

# example of code for Line 3874 (the first : "if (wheel_y != 0.0f)")
bool noScroll;
while (1) { // Line 3874
   noScroll = 
       (window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs);
     IF ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.y == 0.0f) || (noScroll))) {
        window = window->ParentWindow;
        continue;
     }
     break;
}
if (!noScroll) // line 3876

So above I just :

• replaced an overly long "set anonymous boolean and test it" in the while loop, by decomposing it in a explicit named boolean before (having a relevant name)
• replace the "WHILE ... window = parent" with a "assign + IF ... { window = parent ; continue } else break".

This is ugly but it's an example just to show that it's just a "sed replace" of some "text" (and the WHILE loop modified to continue/break to be sure to correctly set the boolean which was previously set "anonymously" in the condition of the loop itself.

This uglyness is easily fixable : just negate the proposed "IF" and make it break if the negated == true, otherwise just "window = parent" and then "naturally" (implicitly) "continue" (by not breaking...) :

# example of code for Line 3874 (the first : "if (wheel_y != 0.0f)")
bool noScroll;
while (1) { // Line 3874
   noScroll = 
       (window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs);
     IF NEGATION((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.y == 0.0f) || (noScroll))) {
        break;
    window = window->ParentWindow;
}
if (!noScroll) // line 3876

(yeah, replace "IF NEGATION" above by "if !", that was for emphasis.)

I think that would reaaally simplify intention of the code at Line 3874 and 3876

imgui/imgui.cpp

Lines 3871 to 3876 in 612b787

	if (wheel_y != 0.0f)
	{
	StartLockWheelingWindow(window);
	while ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.y == 0.0f) || ((window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))))
	window = window->ParentWindow;
	if (!(window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))

And of course it would also be applied at the same test for X below :

imgui/imgui.cpp

Lines 3888 to 3890 in 612b787

	while ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.x == 0.0f) || ((window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))))
	window = window->ParentWindow;
	if (!(window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))

This would really for code readability (factoring) of this section, which currently somewhat hampers fixing the code issue of the behavior described in #3795.

3) The bug fix...

...Following up on this one in another comment below..

[folays]

3) The bug fix...

Regarding

imgui/imgui.cpp

Lines 3871 to 3882 in 612b787

	if (wheel_y != 0.0f)
	{
	StartLockWheelingWindow(window);
	while ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.y == 0.0f) || ((window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))))
	window = window->ParentWindow;
	if (!(window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))
	{
	float max_step = window->InnerRect.GetHeight() * 0.67f;
	float scroll_step = ImFloor(ImMin(5 * window->CalcFontSize(), max_step));
	SetScrollY(window, window->Scroll.y - wheel_y * scroll_step);
	}
	}

It still has the same issue.
As said on #4559, on a MacBook with the internal touchpad, EVEN if you try REALLY HARD to move your finger "only on X", it superhard to do and if you have success, it's only for 10 pixels maximum, then you will inevitably also move your finger "on Y".

As soon as you "inevitably" move your finger on Y, the "wheel locked window" (StartLockWheelingWindow(window)) will bubble up to the first parent having interest for Y.

You will as such be "locked out" of your capability to "scroll on X", and you will recover only if you raise your finger and wait the amount of time "unlocking" the "wheel locked window" as done by ImGui.

Concretely, this is really nearly impossible to scroll on X on a touchpad.
Maybe the hardware/driver of some MacBook have some small differences, but on mine (MBP Pro 13" August 2020) it's really super super hard to scroll on X, that's not usable at all really :(

The Patch

Well, the core of the problem is that the logic is first applied to Y, then to X.

It has some senses when, as @ocornut said, there is "two streams" of independent values, like when you for real have 2 physical scrolls, the human user could be sufficiently intelligent to understand to not scroll both at the same time when this problem occurs.

fdbce6c

My original patch proposal above (fdbce6c), which should be read in "diff mode" of "side-by-side" so as not to go crazy,
"changes" and "merges" the behavior of the 2 loops:

• BEFORE : If scrollY != 0, Loop on window=parent on some condition, and then do the same on scrollX != 0
• AFTER (my proposal) : "merge" the 2 loops to figure out the "bubbling up" of the event.

My patch aimed to:

stop bubbling the event as soon as a widget has interest for either scroll-x or scroll-y.

If the widget has interest for only one of the two scrolling axes, the second axe will be ignored, which is probably the better situation. (it will NOT be bubbled up to the parent).
Of course if the widget has interest for BOTH axes, it will correctly receive both events.

I'm not sure that it would be a bug, I think that maybe it's a feature.
Regarding "scrolling two axes both at the same time" (being on 2 reals physicals wheels, or on a touchpad) :
-> I'm not sure any sane user would like to have those two "concurrent" events (at the same time, a scroll both on X and Y) to HAPPEN on TWO DIFFENTS window/widget (selected by the while/if "window = parent").

My patch does not seem far behind "master" and the logic change (merging the 2 loops) seems to be possibly applied easily.

[folays]

I should also add that, as one of the other issues explained, there is a quicker way to test the behavior with the "demo":

• run the demo
• do not go for "Tables & Columns". More quicker, go for the "menu" and chose the "Examples" menu then "Log" in the drop-down (the 3rd item).
• Click to "add 5 entries"
• resize the window so that there is a scrollbar on X (horizontal) and no scrollbar on Y (it should probably not, since there is only 5 lines...)

On a MBP Pro 13" August 2020, this is nearly impossible to scroll on X.

You somewhat just achieve it by luck with ~10 pixels max at each try, by trying to have a steady hand/finger, and moving your finger only on X, which is superhard.

[folays]

Hi, I updated my branch :)

Please consider merging this request, I beg you.

Scrolling does not work AT ALL in some conditions on MacBooks with touchpad. Since at the very least February 2021 (my original request), but I guess since way more time.

Just try on a Macbook scrollpad the following :

run the demo (I use examples/example_glfw_opengl3)
Run from the menu, the "Examples / Log" item in the drop-down (the 3rd item).
Click to "add 5 entries"
resize the window so that there is a scrollbar on X (horizontal) and NO (VERY important) scrollbar on Y (it should probably not, since there is only 5 lines...)
On a MBP Pro 13" August 2020, this is nearly IMPOSSIBLE (99% difficulty) to scroll on X.

You somewhat just achieve it by luck with ~10 pixels max at each try, by trying to have a steady hand/finger, and moving your finger only on X, which is superhard.

As soon as you add many more "5 entries" up to to the a scrollbar on Y appears, the problem disappear.

My branch (and the following patch) fixes that.

The caveat is both event (scroll Y AND scroll X) will STOP bubbling up as soon as a window has interest / utility.
(and this is probably NOT a caveat, because scrolling BOTH AT THE SAME TIME on TWO DIFFERENT WIDGETS would probably be super weird)

The diff is :

--- a/imgui.cpp
+++ b/imgui.cpp
@@ -4296,27 +4296,23 @@ void ImGui::UpdateMouseWheel()
         wheel_y = 0.0f;
     }

-    // Vertical Mouse Wheel scrolling
-    if (wheel_y != 0.0f)
+    if (wheel_y != 0.0f || wheel_x != 0.0f)
     {
         StartLockWheelingWindow(window);
-        while ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.y == 0.0f) || ((window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))))
+        bool noScroll = (window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs);
+        while ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.y == 0.0f && window->ScrollMax.x == 0.0f) || noScroll))
             window = window->ParentWindow;
-        if (!(window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))
+
+        // Vertical Mouse Wheel scrolling
+        if (!noScroll && wheel_y != 0.0f)
         {
             float max_step = window->InnerRect.GetHeight() * 0.67f;
             float scroll_step = ImFloor(ImMin(5 * window->CalcFontSize(), max_step));
             SetScrollY(window, window->Scroll.y - wheel_y * scroll_step);
         }
-    }

-    // Horizontal Mouse Wheel scrolling, or Vertical Mouse Wheel w/ Shift held
-    if (wheel_x != 0.0f)
-    {
-        StartLockWheelingWindow(window);
-        while ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.x == 0.0f) || ((window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))))
-            window = window->ParentWindow;
-        if (!(window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs))
+        // Horizontal Mouse Wheel scrolling, or Vertical Mouse Wheel w/ Shift held
+        if (!noScroll && wheel_x != 0.0f)
         {
             float max_step = window->InnerRect.GetWidth() * 0.67f;
             float scroll_step = ImFloor(ImMin(2 * window->CalcFontSize(), max_step));

But the diff is somewhat un-readable unless in "split view".

The result of applying it is :

    if (swap_axis)
    {
        wheel_x = wheel_y;
        wheel_y = 0.0f;
    }

    // UNCHANGED CODE ABOVE, NEW CODE BELOW...

    if (wheel_y != 0.0f || wheel_x != 0.0f)
    {
        StartLockWheelingWindow(window);
        bool noScroll = (window->Flags & ImGuiWindowFlags_NoScrollWithMouse) && !(window->Flags & ImGuiWindowFlags_NoMouseInputs);
        while ((window->Flags & ImGuiWindowFlags_ChildWindow) && ((window->ScrollMax.y == 0.0f && window->ScrollMax.x == 0.0f) || noScroll))
            window = window->ParentWindow;

        // Vertical Mouse Wheel scrolling
        if (!noScroll && wheel_y != 0.0f)
        {
            float max_step = window->InnerRect.GetHeight() * 0.67f;
            float scroll_step = ImFloor(ImMin(5 * window->CalcFontSize(), max_step));
            SetScrollY(window, window->Scroll.y - wheel_y * scroll_step);
        }

        // Horizontal Mouse Wheel scrolling, or Vertical Mouse Wheel w/ Shift held
        if (!noScroll && wheel_x != 0.0f)
        {
            float max_step = window->InnerRect.GetWidth() * 0.67f;
            float scroll_step = ImFloor(ImMin(2 * window->CalcFontSize(), max_step));
            SetScrollX(window, window->Scroll.x - wheel_x * scroll_step);
        }
    }
}

[ocornut]

Hello,

The PR doesn't address the reported issue that the noScroll was not locked to initial window, which probably always made me consider it as "look again later".

The caveat is both event (scroll Y AND scroll X) will STOP bubbling up as soon as a window has interest / utility.
(and this is probably NOT a caveat, because scrolling BOTH AT THE SAME TIME on TWO DIFFERENT WIDGETS would probably be super weird)

The problem I see presently is that most/many windows will have (ScrollMax.x > 0.0f), which is not very noticeable in most case, and not often taken advantage of, and the change effectively disable the bubbling back to parent when using a regular mouse wheel.

So imagine this situation:

• Window A has a visible vertical scrollbar
• Child B (inside Window A) has no visible scrollbar, but (ScrollMax.x > 0.0f) which is common.

ImGui::Begin("Window A");
for (int n = 0; n < 10; n++)
    ImGui::Text("%*s some contents", n, "");
ImGui::BeginChild("Child B", ImVec2(0.0f, 200.0f), true);
ImGui::Text("this is a long line of text. this is a long line of text. this is a long line of text. this is a long line of text. ");
ImGui::EndChild();
for (int n = 0; n < 10; n++)
    ImGui::Text("%*s some contents", n, "");
ImGui::End();

With the proposed change, vertical wheeling while over Child B doesn't bubble back Window A anymore.

While it's not as problematic as your current issue, it is problematic and I was hoping this would get resolved.

[ocornut]

Could you add in UpdateMouseWheel()

IMGUI_DEBUG_LOG("MouseWheel X:%.3f Y:%.3f\n", wheel_x, wheel_y);

And record logs of:

• Trying to do a few vertical swipe.
• Trying to do a few horizontal swipe.
• Trying to do a diagonal swipe and round gesture.

I am trying to understand is MacOS does some filtering/axis locking at all.
If you try to do slow or fast vertical/horizontal swipe, do you notice if osx filters things on fast swipes?

When you try to have a steady hand and try to "only move X", well, after some tries, sometimes:
you "successfully" scroll ONLY X on some pixels
then farther the scrolling you do, the fastest you "lose your luck" (your finger move a little "vertically")...
...and so OS X will also emit a Y change, and then the problem exhibits.

OK I now understand another aspect/subtly of this bug which I previously didn't see.
On the frame where suddenly both wheel are != 0.0f, bubbling happen for wheel_y, and that final "bubbled" value of window is used in the wheel_x codepath to call StartLockWheelingWindow() on the window bubbled by wheel_y, which now incorrectly locks again higher up. This is one aspect of this issue. I'm pushing some debugging stuff to look into that.

[ocornut]

Sorry for late reply and thanks for the careful investigation and details.

Maybe I should try with a non-WebKit browser this webpage to figure out if this behaviour is WebKit-specific or some macOS per-application configuration...

Any luck with that?

OK I now understand another aspect/subtly of this bug which I previously didn't see.
On the frame where suddenly both wheel are != 0.0f, bubbling happen for wheel_y, and that final "bubbled" value of window is used in the wheel_x codepath to call StartLockWheelingWindow() on the window bubbled by wheel_y, which now incorrectly locks again higher up. This is one aspect of this issue. I'm pushing some debugging stuff to look into that.

This part of fixed with 80a870a (slight refactor) + c7d3d22 (mitigation/fix for #4559), but this main issue remains totally open. Unfortunately PR as this will conflict (rebase/fix if you want to further investigate, but not strictly needed).

Also unfortunately, this issue is tricky enough it's not easy to get back to it after some time.

IF I'm already at the bottom of the "Simple Inner" AND I left the trackpad alone roughly ~200-300ms,
(both condition), then a further "scroll-Y down" impulse will make the WEBPAGE scroll down.

(1) I tweaked the logic in 80a870a. Notice it's not only a timer change: previously timer was not reset on further wheeling (which seemed very weird) now it is reset. TBH maybe now that it is reset on wheeling we should lower down that value much more (intuitively maybe 0.5f~0.8f may be better).

(2) Bubbling-up for same axis (when already at min/max) is something we should add indeed. Not the core of this issue but would be good. Can be developed separately.

---

Based on the discussions and data points above here's what I think we should do:

- WindowA
  - ChildB (hovered)

When needing to determine locked window for wheeling.

• (1) do a bubble-up scan to check the first window which could use ScrollX and ScrollY.
• (2) if only one is claimed, or both are claimed by the same window -> we have no problem.
• (3) select closest axis (one used by ChildB). if the other axis value if 0.0f we can lock on ChildB > no lag. based on your logs/samples I suspect we'll have no false positive. (the issue would be e.g. user expecting to do a Y scroll, and Frame N has X != 0.0f, Y = 0.0f. If we later have reports of this we can decide to skip step 3 - see 3B - but honestly I expect trackpad drivers to have a say before we even have access to that data, and would prevent that).
• (4). if we couldn't lock on step 3, prevent scrolling on Frame N+0. On Frame N+1 calculate the movement magnitude for both axises for both frames, select best axis and lock from here.

Once locked:

• (5) if same window wants both axis: implement a heuristic to update "main" axis. e.g. update two sets of compact moving average of magnitude over 100 ms. except we probably want to consider supporting a "clearly both axis" mode based on a moving average of a longer period that needs an initial unlocking. So that heuristic would have 3 output: axis X, axis Y, axis XY.

Additional heuristic to detect mouse type:

• (3.B) As pointed out, majority of mouse will never have this issues. If we implement Step 3 as is, regular mouses will never have a frame delay. However if we end up needing to disable 3 due to false positive reports, we should develop an additional heuristic to guess if the user is on trackpad device that emits dual axis. I don't want to create logic/heuristic that will forever "lock" the system to either as some user may be alternating between both, but as long as we develop a heuristic that merely "hitches" at the time of switching devices we good.

Same axis bubbling-up

• (6) As pointed above we can also bubble-up on same axis when reaching min/max, that's merely an alteration of (1) that we can develop and test before or after all other points.

What do you think?

Going to start writing a little test bed for this (I'll have to write it blind as I don't have access to the Mac right now).

[ocornut]

WIP branch
https://github.com/ocornut/imgui/tree/features/mouse_wheeling_target_3795

Will update branch over time but first push has:

• Shallow refactor (to simplify diff of second commits) + timer tweak 4529abf
• Main work a1fad4d

This aims to implement (1) (2) (3) (4) but not well tested yet.
There's a commented line which should implement (6) but not tested at all.
I think (5) is quite desirable otherwise trackpad will often perform accidental X scroll. The commit adds a unused ImExponentialMovingAverage() helper which will be helpful for (5).

[ocornut]

I reworked this as fe07694 (same branch), it now handles selecting a main axis.

• I guess it'll work well for "intending a single axis"
• But changing axis while scrolling is not tuned and currently depends on a frame count (should use a wallclock time thing?)
• But essentially disable 2D scrolling

Would appreciate test impressions and perhaps a review. I haven't run that on a Mac yet.

[ocornut]

I worry that a long trail of small/inertia mouse-wheel events may unnecessary prevent changing axis when the axis change leads to a target window change, so may need to rework that. If the axis change is on a same window it'll however work fast.

Unfortunately that means another refactor..

[folays]

Hello, thanks for all your work, and I'm really sorry to not have answered quicker :(

I tested against upstream/features/mouse_wheeling_target_3795 c41f267

1. The WheelingWindowWheelRemainder seems to do its job, or at least does not introduce unwanted behavior.
   Even when I'm trying to be "ambiguous" / "false pretend", I have the impression that your code choose the good axis.

   • In FindBestWheelingWindow() where you're writing "Subsequent frames:", (plural form) maybe replace ? :
     (before__) : .WheelingWindowWheelRemainder = wheel;
     (proposal) : .WheelingWindowWheelRemainder += wheel; // ACCUMULATE instead of replacing ?

2. //// - a child window doesn't need scrolling because it is already at the edge for the direction we are going in (FIXME-WIP) : indeed it does not work since it Not Yet Implemented

3. scrolling on both axis at the same time (inside one unique child), when it was clearly the intention :
   Not Yet Implemented as you said. Real probable usage sensical cases :

   • In a "text" child : of course it's probably NOT wanted because it's confusing and not readable pleasurably.
   • In a "image" child : (like a in "image viewer / editor ") it could be usefull. Your eyes would be okay in scrolling both axis.

4. Timer :

   • 0.8s of locking the axes seems way too much. I must now go, but I will do some tests of seemlingly acceptable timeouts.
   • Trashed inertia : When you scroll quickly with the touchpad and "lift" your fingers, the "virtual" wheel still has inertial, which should probably NOT "reset" the timer to full 0.8s WHEN the "inertial" did NOT have any visible effect (scrolling past limit) :
     because when an user did scroll, if the inertia "continues" to ... "non"-scrolling, then the user probably expects a quick "scrolling on another axe" to execute. which will not if the previous axis was still locked.

Regarding (2) the "edge direction WIP"/ "scrolling_past_limits" :

• are you sure you would want to activate it for every one ?
• Or should it be _Window_Flags_Enablable ?
  • An user could be "prison-locked" inside a child window, if a child window were to disable it on both axis AND the child "displayed" X/Y area exceeded whole parent display area.
    (if whole displayed surface of the parent is used by the child, and the user cannot "get out" of the child if the child scrolling event "exceeding limits" does not bubble up to the parent, so that the parent cannot scroll the child out...)

Kind Regards,

8<---8<---8<---

BTW it seems that you "adopted" the terminology of naming things "bubbling" / "bubble up".
That's not really mine and I reused from other GUI frameworks, but if you find it cool, you can name :

• sinking phase : when you find the deepest child
• bubbling phase : when you "bubble up" to find which parent is interested in the event

[ocornut]

(1)

0.8s of locking the axes seems way too much. I must now go, but I will do some tests of seemlingly acceptable timeouts.

The same timer is currently used to lock the window itself (in a situation where e.g. you are vertically scrolling in parent and temporarily have mouse over a child which could accept vertical scrolling). I don't think that timer can be reduced to significantly lower amount (e.g. 0.2 seconds).

• Ideally we can refactor to have one timer for "same axis lock" and another timer for "axis change lock".

---

(2)

Trashed inertia : When you scroll quickly with the touchpad and "lift" your fingers, the "virtual" wheel still has inertial, which should probably NOT "reset" the timer to full 0.8s WHEN the "inertial" did NOT have any visible effect (scrolling past limit) :
because when an user did scroll, if the inertia "continues" to ... "non"-scrolling, then the user probably expects a quick "scrolling on another axe" to execute. which will not if the previous axis was still locked.

What I currently did was to modulate the time increase for small (sub-pixel) wheel amounts: (committed a582d92)

static void LockWheelingWindow(ImGuiWindow* window, float wheel_amount)
{
    ImGuiContext& g = *GImGui;
    if (window)
        g.WheelingWindowReleaseTimer = ImMin(g.WheelingWindowReleaseTimer + ImAbs(wheel_amount) * WINDOWS_MOUSE_WHEEL_SCROLL_LOCK_TIMER, WINDOWS_MOUSE_WHEEL_SCROLL_LOCK_TIMER);
    else
        g.WheelingWindowReleaseTimer = NULL

The axis is still locked during that inertia but this avoid the extra +WINDOWS_MOUSE_WHEEL_SCROLL_LOCK_TIMER delay.

• I think this needs to be reworked more to allow an axis-change to unlock earlier, which is consistent with the need in (1) to have two timers.
• Or simpler, gating the logic on an arbitrary threshold may lower the amount of inertia, barely noticeable for user but I suppose we can halve the time this way.

---

(3) I initially reworked the per-axis average to not be framerate dependent, changing:

// Maintain a rough average of moving magnitude on both axises
// FIXME: should by based on wall clock time rather than frame-counter
g.WheelingAxisAvg.x = ImExponentialMovingAverage(g.WheelingAxisAvg.x, ImAbs(wheel.x), 30);
g.WheelingAxisAvg.y = ImExponentialMovingAverage(g.WheelingAxisAvg.y, ImAbs(wheel.y), 30);

To a rough equivalent:

// Maintain a rough average of moving magnitude on both axises
g.WheelingAxisAvgAccum += ImVec2(ImAbs(wheel.x), ImAbs(wheel.y));
g.WheelingAxisAvgAccumTimer += g.IO.DeltaTime;
while (g.WheelingAxisAvgAccumTimer >= 1.0f / 30.0f)
{
    g.WheelingAxisAvg.x = ImExponentialMovingAverage(g.WheelingAxisAvg.x, g.WheelingAxisAvgAccum.x, 15);
    g.WheelingAxisAvg.y = ImExponentialMovingAverage(g.WheelingAxisAvg.y, g.WheelingAxisAvgAccum.y, 15);
    g.WheelingAxisAvgAccumTimer -= 1.0f / 30.0f;
    g.WheelingAxisAvgAccum = ImVec2(0.0f, 0.0f);
}

Since the average are only compared to each other the exact delay doesn't matter.

However I realized this was wrong as our expectation is to use the average for Frame N+1 comparison.

Then I realized the whole Frame N+1 idea described in #3795 (comment) and implemented in the branch is incorrect, as on very fast / unthrottled framerates it is unlikely the OS would submit wheel events at same rate.

• Instead we should condition the average-compare test (return (g.WheelingAxisAvg.x > g.WheelingAxisAvg.y) ? windows[0] : windows[1];) to start on 1) the second wheel event or 2) a short (e.g. 1/30) time threshold from the first wheel event, whichever happen sooner.

---

(4)

Regarding "edge direction WIP"/ "scrolling_past_limits" :
are you sure you would want to activate it for every one ?

• I'm not and I didn't even attempt to activate it yet. I think we can evaluate this later.

I hoped to finish this for 1.89 but unfortunately it's becoming too risky to commit before tagging, but hope to get back to this asap.

[ocornut]

I have pushed 87caf27 already which is essentially the version discussed in my last message.
I believe there are many improvements to do (mentioned above) but the current version being a definitive improvement I am pushing it already, keeping this open.

[ocornut]

Replying to myself:

(3)

Then I realized the whole Frame N+1 idea described in #3795 (comment) and implemented in the branch is incorrect, as on very fast / unthrottled framerates it is unlikely the OS would submit wheel events at same rate.

It may not be a problem since in all the "ambiguous" data sets above (= both axises non-zero on frame 0) the next event (frame 1 in your data set) confirms the major axis of frame 0. So assuming Frame 1 event appears on Frame 10 with high-framerate, it may not be much of a problem. But this yet has to be tested properly at very high frame-rate.

---

(4.B) Another thing, while doing some casual testing on Mac one noticeable issue was, with this setup:

Window A (Y scroll + minor amount of X Scroll)
 - Child B (X Scroll)

• Start with an Y Scroll,
• Switch to an X Scroll on the same Window A.
• Soon hitting the edge of X Scroll.
• But at this point every further X Wheel input is increasing the timer, which stays locked on Window A.

Here we'd like to eventually start scrolling Child B. It is a sort of "opposite" situation as point (4), going from Parent to Child instead of Child to Parent.