You are here

Feature request: pixel scrolling on supported trackpads, as well as improving the current scroll implementation regardless

2 posts / 0 new
Last post
Last seen: 3 years 6 months ago
Joined: 2020-03-25 00:56
Feature request: pixel scrolling on supported trackpads, as well as improving the current scroll implementation regardless

Modern laptops, perhaps as a response to Apple's magic trackpads, implement "pixel scrolling". In the past, Windows would scroll 3 lines at a time. This was best suited towards mice, where scroll wheels have notches and each notch would scroll 3 lines. Trackpads in Windwows in the past scrolled 1 line at a time, still very jolty. With the advent of multitouch capable trackpads, pixel scrolling means Windows and supported apps will scroll a pixel at a time. The best way to describe this is the scrolling experience on a smartphone. When you flick to scroll, the content moves exactly at the speed of your finger. It clings to your finger. You can scroll as much or as little as possible, pixel by pixel. You can change direction mid-scroll and scroll back the other direction. You can jiggle your finger and the view will jiggle along with it. The only difference with a smartphone and laptop is that the smartphone screen combines the display and the scroll surface. On a pixel scrolling trackpad, the display is seperated from the scroll device. But there is still a 1:1 mapping between how much you scroll and how much the content moves. This is a very comfortable user experience.

PortableApps's menu does not pixel scroll. On top of that, it seems to lag behind the scroll wheel. Let me explain the previous point first.

On a non-pixel scrolling device, such as an ordinary mouse, scrolling up and down over and over again on a list will jump rapidly and immediately. Scrolling is instanteous. Scrolling a few notches on the mouse moves the content a few lines down. Scrolling many notches moves the content many times down. However both occur in the same amount of time. Thus, scrolling fast will move the content faster. In PortableApps' menu, scrolling seems to occur at a uniform pace. This effect is not noticeable when scrolling slowly. However, scrolling fast does not move the view faster. Instead, it moves the view up/down for a longer distance. This means that scrolling fast or slow in the menu does not matter, it's equally slow. On top of that, once a scroll is initiated, the menu seems to "lock" the input until that scroll is complete. Let's say I scroll 10 units down. The menu scrolls 10 units down. However if the menu hasn't completed scrolling 10 units down and is on scroll #5, and I scroll back up 10 units, that means that even though my last input was an upward scroll, the menu is still scrolling down and will not cancel the scroll and go back up. Only when it finishes scrolling 10 units does it begin to move up. To exagerate this, scroll up and down very fast on the menu. You will immediately notice that there is no way to predict the scrolling: my finger may be moving up but the content is moving down, and vice versa. My finger may not be on the scrollwheel but the app list is still scrolling up/down, because it hasn't finished it's list of "queued" scrolls. This seems to be because PortableApps's menu is using it's own scrolling implementation. I propose PortableApps uses the OS's inbuilt scroll view.

My first point, the pixel scrolling, simply exacerbates the above issue. Pixel scrolling trackpads can scroll a large distance in a short timeframe if you flick rapidly enough. This means that when scrolling fast on a pixel scrolling trackpad, there is a huge amount of lagtime while the PortableApps menu is still waiting to finish the scroll. It also means that it takes a long amount of time to get from the top of the list to the bottom: with pixel scrolling, a well placed flick can send you flying to the end of the list.

In PortableApps's menu, scrolling thus becomes a painful experience, regardless of mouse, trackpad, pixel scrolling trackpad. One is forced to use the scrollbar or search.

I have recorded 3 videos:
the first, a pixel-scrolled trackpad scrolling the the PortableApps menu, showing scrolling lag, and unpredictability of scrolling
the second, pixel scrolling on a Windows 10's start menu, showing 1:1 mapping between finger and content, direction changing, and quick scroll to top/bottom
the third, line scrolling on a web browser vs line scrolling on the PortableApps menu, showing the ability to change directions "jiggle" in the web browser, and the lag (waiting for previous scroll to finish before starting the next) while using PortableApp's menu.

John T. Haller
John T. Haller's picture
Last seen: 12 hours 7 min ago
Joined: 2005-11-28 22:21

This is a bit complicated to implement. The current menu is actually a series of 20 individual controls. So per-pixel is physically impossible. If the implementation changes - requiring a pretty significant rewrite - that may change.

As for the others, I'm switching the scroll setup to be adaptive and scroll based on how far the wheel/trackpad slide is rather than just a simple up/down. So, if you scroll a lot, it'll scroll multiple lines as a single go. I also added support for Windows' number of lines to scroll setting for the wheel. It's in the list here now:

Sometimes, the impossible can become possible, if you're awesome!

Log in or register to post comments