Improved scroll wheel support

We are currently investigating !Store’s catalogue window – it initially seemed simple, but seems a little more complex than at first thought.

Where should we be with !Edit scrolling?

…

With OS 5.27 (07 May 2020) !Edit scrolls one line at a time, but with OS 5.27 (18 May 2020) it scrolls 4 lines at a time and does not follow scroll settings. The difference being this.

With current ROMs Edit should scroll five lines at a time (or near enough, due to the way Edit snaps the top/bottom of the window to a character boundary). This essentially reverts it to the old behaviour from when USBDriver was generating scroll requests itself (since it would always do them five at a time).

Having it react to the scroll speed setting would be nice, but some thought is needed on how best to handle that (as discussed in this post) – so I’ve put that on the back-burner while I work on other issues.

It’s a NetSurf developer weekend. I’ve been joining in a bit. How NS responds to scrolling is being looked at now.

Yes, it’s probably a bit on the big side. But I’d assumed it was a conscious design decision, rather than a bug (e.g. I’d expect to see the same behaviour on RISC OS Select)

However, some archaeology leads me to this commit where support for extended scroll requests was first introduced:

http://git.netsurf-browser.org/netsurf.git/commit/?id=7fbb51d79903dffc26ca8f295cc770f83b6ad7ff

The code is broadly the same as it is now, but there’s one key difference which suggests that the current behaviour might actually be a bug in NetSurf: some code has crept in which multiplies the scroll delta by two.

Old code – page up is +y, extended scroll is (y * (scroll→ymin>>2)) >> 2 (one quarter window height per wheel tick)

New code – page up is SCROLL_PAGE_UP, which gets mapped to +visible_y just below. Extended scroll uses step_y = -((visible_y * (scroll_y>>2)) >> 2), but then further below it gets applied as state.yscroll -= 2 * step_y, so now it’s scrolling in half-window chunks instead of quarter-window chunks.

However I haven’t tracked down when the *2 was introduced, so maybe that was a deliberate change.

Okay, thanks. I could not work out what all the dividing by 4 was until I found some documentation here:

https://www.riscosopen.org/wiki/documentation/show/Scroll%20Directions

That explains the (scroll_y>>2), but not the second >>2. The documentation also says that it means scrolling by N times, but it doesn’t explain what N should be a multiple of, so I don’t know what to expect for N values.

For now I’ve just made it N*32 pixels. http://git.netsurf-browser.org/netsurf.git/commit/?id=5af4e79197b8552e2f78a348511ae276c9f0e990

Does that behave okay? Please could someone test build #5143 or later.

https://ci.netsurf-browser.org/builds/riscos/?C=M;O=D

If its acting weirdly, please see what values are getting logged on lines like: “Extended scroll request with N=<???>”.

Hi Michael,

Seems better to me but I will defer to others to check as well.

This is on a ARMX6 , 5.27 19-May-2020.
Multiple line unticked in the new Mouse configure gadget and target under the pointer.

Log as below when scrolling these forums and hope that helps.

browser_window_history_update: Updated scroll offsets to 0.0451354 by 0.472056
(26.660000) [INFO netsurf] content/content.c:665 content_add_user: content https://www.riscosopen.org/favicon.ico (0×5aacac08), user 0×16be58 0×5abff720
(29.680000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(30.620000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=4
(32.200000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=4
(32.720000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=4
(33.180000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=4
(33.320000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=4
(33.910000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=4
(34.470000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=4
(35.010000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=4
(35.600000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(35.640000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(35.720000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(36.160000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(36.660000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(37.080000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(37.480000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(37.560000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(37.920000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(38.290000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(38.350000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4
(38.640000) [INFO netsurf] frontends/riscos/window.c:1153 ro_gui_window_scroll_action: Extended scroll request with N=-4

Please could someone test build #5143 or later.

CI #5143 scrolling looks “just right” to me on OS5.27 (24May20) on a Titanium and RPi4 and also on OS5.26 on a RPi1. It is about the same rate as NetSurf 3.9 on OS5.26. The new speed is fixed, that is not dependent on the mouse speed configuration.

Please could someone test build #5143 or later.

Indeed. That seems fine on an ARMX6 now, much more usable.

Okay, great, thanks! I’ve removed the extra scroll request logging now.

Where is this “new Mouse configuration gadget”?

Where is this “new Mouse configuration gadget”?

Configuration

Mouse Setup 0.17 (28-Mar-20)

Where is this “new Mouse configuration gadget”?

More precisely in the latest ROOL beta Hard Disc download.

More precisely in !BOOT.RO500Hook.Res – thanks.

So the new behaviour doesn’t change with the scroll wheel scroll speed setting, either in NetSurf or in Zap. Is there an app that definitely does respond to the setting, so I can be sure it works?

This is an RPi 3B+ with RO of 3 days ago. I’m assuming that I don’t have to update anything else from HardDisc4 apart from the Configure stuff.

Is there an app that definitely does respond to the setting, so I can be sure it works?

StrongED 4.69f11 and Fireworkz 2.24.06 do.

Thanks. I’ve also realised that filer windows do too.

So the app has to set either bit 8 or 9 in its window flags, then Scroll_Request Wimp events come through. Then… I don’t see, from the paper PRM3, how the size of the step is given.

Edit: Got it, use the wiki version of the PRMs.

So the app has to set either bit 8 or 9 in its window flags, then Scroll_Request Wimp events come through. Then… I don’t see, from the paper PRM3, how the size of the step is given.

It won’t be in the paper PRM3, I wouldn’t think… It’s a new¹ interface.

Try this or perhaps this if the API is similar.

Do you not need the “extended scroll requests” flag in the extra window flags set, or have I misunderstood?

¹ Well, 20 years old.

Do you not need the “extended scroll requests” flag in the extra window flags set

Yes, you do. There’s a mystery because the window definition does appear to have all the right flags set, subject to a check of the numeric values of the constants being correct, but the scroll directions always appear as +/-4.

Does anyone know whether there is a difference between the values returned if the auto-repeat and/or non-auto-repeat flags are set?

I don’t see, from the paper PRM3, how the size of the step is given.

The size of the step isn’t given. That’s the biggest flaw with the API.

• The original Scroll_Request doesn’t tell the app how many OS units to scroll because the whole idea behind Scroll_Request was to allow the app to decide for itself how far to scroll
• The extended Scroll_Request doesn’t tell the app how many OS units to scroll either. I’ve got no idea why – was it two different people who invented extended scroll requests and the “scroll speed” setting? Is there some secret API for reading it which ROL haven’t documented?

The only way in which WindowScroll (or other code) can directly dictate how far a window should scroll is by using “open window” messages. But the WindowScroll spec implies that the priority order for mouse wheel scroll events should be:

1. Use an extended scroll request (if the app opts in to them)
2. Else use original scroll requests (if the app opts in to them, and “line scroll” is enabled)
3. Else use an open window request

For number 2, WindowScroll is able to fake support for the scroll speed setting by reading back how far the window has scrolled and using that to guess how many more scroll requests need to be generated. Obviously this will only work properly if the window scrolls in response to the scroll request; if it does something else (like scrolls a non-Wimp bit of UI, or zooms the window) then WindowScroll won’t be able to calculate the scroll delta and so you’ll only get basic, un-scaled scrolling (one scroll request per wheel “tick”)

For number 1, I’d say that the entire point of extended scroll requests is to allow apps to do unusual things in response to mouse wheel input – things like scrolling icons, scrolling non-Wimp bits of UI, or not scrolling at all (e.g. zooming). Having WindowScroll attempt to measure the response to extended scroll requests is therefore a lot less reliable/unsafe, so it simply doesn’t bother.

Since NetSurf wants to scroll non-Wimp bits of UI (HTML frames), and wants to be able to zoom in response to wheel input, I’d say that (the current incarnation of) extended scroll requests are the right thing for it to be using.

This post contains some of my thoughts on how we could extend the scroll request system to allow WindowScroll to directly dictate the scroll delta.

the scroll directions always appear as +/-4.

It’s basically 4*N, where N is the number of wheel “ticks”. In reality it won’t quite be that value (it gets applied in smaller chunks over time in order to provide some animation). But if you’re able to scroll your wheel fast enough (or add a delay loop to slow down NetSurf) you should see N>1.

Does anyone know whether there is a difference between the values returned if the auto-repeat and/or non-auto-repeat flags are set?

There is no difference in behaviour.

The extended Scroll_Request doesn’t tell the app how many OS units to scroll either. I’ve got no idea why – was it two different people who invented extended scroll requests and the “scroll speed” setting? Is there some secret API for reading it which ROL haven’t documented?

IIRC there was some code explaining how to differentiate and handle normal/extended scroll. Stepping is left to the application as before, it is just that the scroll x/y parameter (+-4*N case) in the extended scroll should be interpreted as N times the normal scroll.

IRC there was some code explaining how to differentiate and handle normal/extended scroll. Stepping is left to the application as before, it is just that the scroll x/y parameter (+-4*N case) in the extended scroll should be interpreted as N times the normal scroll.

Is it this — which I linked to earlier on?

The size of the step isn’t given. That’s the biggest flaw with the API.

Isn’t the step size up to the program? For example, “a line of text” or “an inch” or whatever makes sense to the program.

DTP/WP, for instance, going up line by line would seem logical. Step size depending upon the size of the text on-screen.
An image viewer (Manga, for example) would be able to get away with larger steps.

Then, the scroll system provides a variable number (positive or negative) to reflect the ‘speed’ of the scroll wheel. Single ticks for going up and down small increments (like a line), or larger values for skipping bigger chunks in one go (and not having a half dozen single scroll requests).

That’s my take on it, anyway…

Is it this — which I linked to earlier on?

Yes but seems my memory was incorrect, the only behaviour reference is the line scroll option which mention “… When enabled, the line (or column) scrolling event will be used, rather than scrolling by an arbitrary amount.” which seems to suggest that a extended scroll is handled as a simple line/column scroll.

!Store seems to scroll OK now.