Trackpad scrolling with momentum doesn't work on OS X.

[StrangeNoises]

I noticed this first with markdown-writer-fx but was able to repeat it just with the Java Keywords Demo after pasting in a source file big enough to scroll around in, therefore reporting it here. On markdown-writer-fx the left-side editor pane, implemented using RichTextFX, exhibits this problem, but in the right-hand pane, which is the non-editable preview output, scroll behaviour works normally, so it looks like it's just the RichTextFX pane.

Basically, with two-finger scrolling with a trackpad one expects the movement to have some momentum to it, so you push, or swipe up or down, with two fingers and release in mid-movement, it glides to a stop. There is none of this in the RichTextFX window/pane, so you can only scroll in short, sharp steps a few lines at a time in exact lockstep with the fingers sliding on the surface. Unsurprisingly this gets old fast. 😉

This does not appear to be the case in Windows (even when it's running as a VM on the mac, in VMWare). Only when running directly in OS X. However it may only be apparently working on Windows because the mouse/pointer events are being mediated by the virtual, emulated, mouse driver, which I'm guessing may be resolving such momentum effects into discrete events. I'm unable to test this on a natively-running Windows, as I have no such beast here.

I don't think it's a general Java FX scrolling issue as, as mentioned, the right-hand preview pane in markdown-writer-fx has normal with-momentum scrolling behaviour that feels completely consistent with that of native Mac apps. Also other JavaFX apps with scrollable areas such as the ControlsFX fxsampler also seem to have normal two-finger scrolling momentum behaviour. So it looks like it might be a difference in the way such scroll events are handled in RichTextFX. e.g.: if a scrolling event that normally works correctly by default is being intercepted and handled completely, losing that expected behaviour along the way.

Scrolling speed and redraw performance itself seems fine; if for instance I just click-drag the scrollbar, everything updates as fast and as smoothly as I could wish it, (although this is a quick computer, I haven't tried it on my RPi2 yet 😉) so it doesn't appear to be just being slow.

... additional observation, noticed just before clicking submit:

two-finger trackpad scrolling is of course 2D. i.e.: you can pan and scan right and left as well as up and down. In the Java Keywords Demo, with a source that has long (too long for Java style guides!) lines of code in it, making the window's logical width significantly wider than its visible width, the X-axis scrolling is behaving normally. I can two-finger swipe left or right and it slides to a halt exactly as I'd expect; but Y-axis is still stuck to my exact finger movements.

[JordanMartinez]

This issue doesn't arise with Linux Mint.

[StrangeNoises]

This problem has gone away for me in OSX, so I'm going to close this. Scrolling using magic trackpad with a big java source pasted into the JavaKeywords demo is behaving exactly as I would expect.

As before, checking with richtextfx-demos-fat-0.6.10.jar. I didn't specify that version in my original report - probably because I'd already established it was still the case with the then-HEAD. But as 0.6.10 was the current stable release as of the time I submitted the original report, I expect the fix isn't actually in this code but possibly in a more recent release of Java/JavaFX itself. (Currently using 8u92; it's possible it was fixed in 8u77, but I never tested in that timeframe.)

edit: Looks like it was probably this: http://bugs.java.com/view_bug.do?bug_id=8152452 although the symptoms don't exactly match what I was seeing (but in JavaFX rather than Swing, and on a later OSX), but the fix seems definitely to have been in the same ballpark.

[TomasMikula]

Thanks for reporting back! It would have cost us a lot of time trying to figure out what exactly was going on.

[shoaniki]

I literally came here to report this exact bug -- so it does not seem to have gone away for everyone.

I am seeing the behaviour reported above with the versions reported above -- RTFX 0.6.10 and Java 8u92 -- as well as with the latest versions available, i.e. the RTFX-1.0.0 snapshot dated June 10 and the Java 8u102 early access release. This is all with a 2016 MacBook running OS X 10.11.5. And, as observed above, this only happens in OS X itself; everything works as expected within a Windows VM on the same computer.

I did a bit of digging to see whether I could figure out anything about the problem. Installing an event filter shows strange things happening. To be precise, if the scrolling hits the edge of the rich text control, everything happens as expected -- it receives a start scroll event, then a sequence of normal scroll events, then a stop scroll when the fingers are released, and finally a sequence of momentum scroll events after that. But if scrolling does not hit the edge, this sequence is terminated early. I see the start scroll event, then maybe six or seven of the normal scroll events, and then -- nothing. No more scroll events, no end scroll event.

So it looks like something is causing the events to stop being sent at all when the recipient is a rich text control that is scrolling ... that's as far as I've got, since I can't claim to understand low-level JavaFX event handling yet!

[StrangeNoises]

Sorry for not coming back on this for ages, I was doing other things. now I'm actually working on code that uses this, and I can report I'm seeing the same thing again as I originally reported, and as per shoaniki. I can only guess that it may have been accidentally fixed in a given release of Java 8, and as it was accidental, was broken again in a later one. Although I still also hope that the fix for this resides in the code here, somewhere.

Not got to the point where I need to fix this for myself now, just noting that I am still/again experiencing it.

[JordanMartinez]

If you add an event handler to the scene, and output all the Scroll Event's data, what does it output? (similar to what @shoaniki did beforehand).

I can only guess that it may have been accidentally fixed in a given release of Java 8, and as it was accidental, was broken again in a later one.

Seems like that to me.

[StrangeNoises]

Some edits for sense.

Incoming! I had to get to a point in my own coding where I was actually using RichTextFX directly rather than indirectly. (I'm writing Yet Another Markdown Editor (not its name) and for getting-something-working-quickly I was appropriating markdown-editor-fx's MarkdownEditorPane. Now I'm not.) At this stage I'm using a completely basic CodeArea with no syntax colouring rules defined yet.

I added a very very simple event filter like this to the CodeArea editor:

        editor.addEventFilter(ScrollEvent.ANY, se -> {
            LOG.info(se.toString());
        });

I added the same to the resulting WebView preview pane, which is scrolling correctly, ie: with the expected momentum-effect when the fingers are lifted from the trackpad while still in motion. I ran it, with a fairly big markdown document in the window and just did a quick two-finger upward swipe (to scroll down) in each window, the editor first, the preview pane second.

The log is attached.
scroll.txt

What it looks like is that there is an initial SCROLL_STARTED, then a few (5 or 6) SCROLL events, then a SCROLL_FINISHED. Then the CodeArea receives one more SCROLL event and that's it. The WebView recieves a ton more SCROLL events after the SCROLL_FINISHED, which I think represent the momentum effect after the user has lifted their fingers and it slows down to a stop. Indeed during this period the deltaY figures seem to reduce, though not consistently or linearly, but the general trend is there.

NB: The same effect was present when I tried not wrapping the CodeArea in a VirtualizedScrollPane, so it doesn't look like that is directly responsible at least. But is it possible (though I can't see it with a quick look at the source) that something is consuming SCROLL events that come in after a SCROLL_FINISHED, presuming there wouldn't be any?

[StrangeNoises]

Additional comment:

I turned wrap text off. Sideways scrolling with inertia is working just fine, only vertical scrolling is broken.

Actually I've just noticed I mentioned that in my very original report too, when I raised the issue. Confirming that it's still true, and using a snapshot built from the current code in master. I've been looking through the code, including at Flowless, and I can't see why it might do this, or be doing anything different for X and Y scrolling.

NB: Side-issue: In the master code, as opposed to 0.7 M2, moveTo(pos) seems to not be working. On 0.7 M2, editor.moveTo(0) moved the caret to the top of the document, and scrolled there too. On master, it's doing nothing.

[StrangeNoises]

OK, another observation that might be relevant:

With wrap text back on, with a document loaded that has long paragraphs each on one logical line (as opposed to preformatted for text like my earlier test material) I'm finding even normal scrolling without inertia isn't working properly when starting scrolling with the pointer over a long paragraph.

I get a SCROLL_STARTED, and maybe one or two SCROLL events, and then nothing. What I experience as a user is that even with the fingers remaining on the trackpad sliding up and down, I only get a scroll of about one line, then it stops.

It's basically like something is cancelling the scroll sequence. I was looking for a way to do that deliberately in the JavaFX API but didn't find it. But that's what it looks like. Long paragraphs make the problem even worse. The longer the paragraph, the quicker it gives up. (edit: scratch that, it doesn't seem to be a reliable pattern, more random than that.)

It doesn't seem to be a problem when actually dragging the scroll bar.

I plugged in a mouse. That seems fine too, but the event behaviour seems different anyway: There are no SCROLL_STARTED events, and of course no inertia events (where ScrollEvent.isInertia() is true), just a succession of separate SCROLL events.

[StrangeNoises]

I've narrowed this down quite a lot. I stuck an event filter into lots of places to log scroll events.

(I also by the way set the real event handler in VirtualFlow to receive ScrollEvent.ANY instead of just ScrollEvent.SCROLL as we want the SCROLL_STARTED and SCROLL_FINISHED events too. That didn't fix it, but I believe is the right thing to do anyway.)

All the events are being received by ParagraphBox and ParagraphText. What happens is that they get lost when that ParagraphBox is orphaned from the Navigator they're in, because it's been scrolled off the top of the viewport. As soon as that happens, the ParagraphBox's parent becomes null and the events no longer bubble up to the VirtualFlow for it to perform the scroll.

I think if you can keep the ParagraphBox instances as children of the Navigator after they've left the viewport, at least until the whole scroll gesture is finished, that might help a lot. I'm not certain that accounts for all the trackpad scroll anomalies I encounter (eg: sometimes where I can barely scroll up or down by a line before it dies), but it is certainly stopping inertial scrolling.

Log attached below, where I basically stuck this code:

        this.addEventFilter(javafx.scene.input.ScrollEvent.ANY, se -> {
            java.util.logging.Logger.getGlobal().info(this.getClass().getName()+": ScrollEvent: "+se.getEventType()+", isInertia="+se.isInertia()+", target:("+se.getTarget().getClass().getName()+"), deltaX:Y: "+se.getDeltaX()+":"+se.getDeltaY());
        });

... into the constructors of VirtualizedScrollPane, StyledTextArea, VirtualFlow, Navigator, ParagraphBox, TextFlowExt. You can see as soon as ParagraphBox's parent goes null, unsurprisingly, the events no longer bubble up to everything above that. In the final run, the event filter for ParagraphBox just has the bit extra to show the parent.

scroll-events.txt

[StrangeNoises]

addendum after a bit more playing. Actually I think that is the whole problem, though I may also have helped a little by having VirtualFlow handle ScrollEvent.ANY, as otherwise you'd lose the first movement which would probably make it feel sluggish. But otherwise, I can now see that if I'm paying attention to which paragraph the pointer is over when I start a trackpad scroll, I can see that it's exactly when that paragraph goes out of the viewport that the scrolling stops.

[StrangeNoises]

I've had partial success in fixing this by catching scroll events in an event filter in Navigator, recording some state, then when it's about to crop cells, asking if there's a scroll event ongoing. Literally:

    private boolean isScrollGestureOngoing() {
        return scrollStarted && (!scrollFinished || lastScrollAtTime > System.currentTimeMillis()-1000);
    }

Partial success: It works for scrolling down the document (pushing up) but getting a redraw issue when scrolling up (pushing down) where the items that would have been cropped instead get stuck at the bottom of the window, overlaying each other like a pile of dead flies at the bottom of a double-glazed window, until the next event of some other kind causes them to be cropped. Problem looks like those items' positions are being clamped inside the viewport, but only when scrolling in that direction, not the other. But otherwise it's working, because the events are bubbling up properly. ;-)

[JordanMartinez]

@StrangeNoises Nice detective work there! Still, if this only arises on OSX, that still seems to be a JavaFX issue. We might be able to workaround that using the approach you're using now, but the fix for Java would be best.