PSA: smooth scrolling enabled on Windows and LInux

[Steve Kobes]

Smooth scrolling is enabled at r367942, and will ship with M49 unless we discover new issues.

Smooth scrolling animates a scroll position in response to discrete scroll input, such as "stepped" mouse wheels or keyboard arrows.  For more info on what smooth scrolling entails and how various platforms are affected, see the doc at bit.ly/smoothscrolling.

This resolves a long-standing feature request in crbug.com/575.

If you experience problems with smooth scrolling, please file a bug (crbug.com/new).  You can disable smooth scrolling in about:flags, though this option may be removed in the future.

Happy scrolling,

Steve

[Rick Byers]

Congratulations Steve and Yash on resolving #8 on the oldest open feature list, and #16 on the most starred open bug list!!!  Can't wait to see this reach stable :-)

Rick

[Steve Kobes]

On Wed, Jan 6, 2016 at 11:19 PM, 一丝 <yio...@gmail.com> wrote:

What time to support the OS X?

Smooth scrolling on OS X is currently enabled for keyboard only, see http://crbug.com/574283 for more details.  If there are any Mac experts out there who want to tackle this one, let me know. :)

[Nico Weber]

On Thu, Jan 7, 2016 at 2:19 AM, 一丝 <yio...@gmail.com> wrote:

What time to support the OS X?

It's been supported on OS X for many years. (Except for mouse wheel scrolling, but that's uncommon on OS X.)

 

以上

一丝

2016-01-07 9:56 GMT+08:00 'Anthony LaForge' via blink-dev <blin...@chromium.org>:

Awesome!

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Steve Kobes]

On Thu, Jan 7, 2016 at 8:06 AM, Jacob G <kurte...@gmail.com> wrote:

Congratz for shipping!

However I'm concerned about the ability to turn it off. What are the long term plans for the switch to disable it?

Firefox gives an option to disable or enable... and smooth scrolling makes scrolling slower for me which is why I've never used it.

For the time being you can disable it in about:flags.

Personally I would not be opposed to adding a user switch for this, although we try to avoid them in general since it increases complexity to support multiple configurations.  But we don't have definite plans in this regard.

[Yash]

On Windows, there is an OS level setting to disable animations inside windows (http://i.imgur.com/fbCFP61.png).

Edge respects this setting and disables smooth scrolling accordingly. Perhaps chrome should respect it too (crbug.com/575222).

[Nojevah N]

Congrats for this long awaited feature.

One remark though: could we not depend on this setting ?

http://i.imgur.com/9Fwf6OH.png

I have to change that setting in Windows (default: 3) in order to have scroll that I want in Chrome.

[Steve Kobes]

On Thu, Jan 7, 2016 at 10:21 AM, Nojevah N <noj...@gmail.com> wrote:

One remark though: could we not depend on this setting ?

http://i.imgur.com/9Fwf6OH.png

I have to change that setting in Windows (default: 3) in order to have scroll that I want in Chrome.

I think Chrome should respect this setting; do you find that it does so incorrectly?  If so please file a bug.

[Nojevah N]

Chrome does (fortunately) not respect the number of lines. For me, this setting is not applicable for smooth scroll.

I entered a bug/feature request accordingly:

https://code.google.com/p/chromium/issues/detail?id=575296

[Joe Mason]

What is different about Chrome that makes the setting that other apps use not appropriate for it?

[Nojevah N]

You don't scroll a web browser as you browse your file explorer obviously.

[Peter Kasting]

On Thu, Jan 7, 2016 at 8:06 AM, Jacob G <kurte...@gmail.com> wrote:

However I'm concerned about the ability to turn it off. What are the long term plans for the switch to disable it?

Firefox gives an option to disable or enable... and smooth scrolling makes scrolling slower for me which is why I've never used it.

We should implement smooth scrolling in such a way that it does not make scrolling appreciably slower.  I've tried to be a bit noisy about that constraint internally, so hopefully we currently abide by it.  If not, please file bugs.

Once smooth scrolling does not meaningfully slow down scrolling for users, I don't think we need a setting for it, or should have one.  This is the sort of small behavioral detail for which Chromium avoids options.

PK 

[Peter Kasting]

On Thu, Jan 7, 2016 at 1:48 PM, Nojevah N <noj...@gmail.com> wrote:

You don't scroll a web browser as you browse your file explorer obviously.

The system setting is not a setting for file explorers, it's a setting for all scrollable viewports system-wide.  Respecting this setting is appropriate and the benefit of adding some sort of configurability for this in Chromium very much does not justify the cost.

PK 

[Nojevah N]

All "smooth scroll" extensions offer a lot of settings, because everybody doesn't scroll the same way.

The implementation in Chrome is good and just need one setting (IMO).

Too bad that "avoid options at all cost" is that popular. As a comparative, there are hidden settings (a lot tbh) in Firefox which allow smooth scroll personnalisation.

[Matt Giuca]

+1 to making it scroll faster (maybe 2x the current speed).

(Is there a constant in the source code I can play with to experiment with different speeds?)

I tried this yesterday and found that it feels "nice" (as in, it appeals to me aesthetically), but it made the whole browsing experience feel sluggish. I suspect it's just because the animation is too long.

[Steve Kobes]

On Thu, Jan 7, 2016 at 3:16 PM, Matt Giuca <mgi...@chromium.org> wrote:

+1 to making it scroll faster (maybe 2x the current speed).

(Is there a constant in the source code I can play with to experiment with different speeds?)

I tried this yesterday and found that it feels "nice" (as in, it appeals to me aesthetically), but it made the whole browsing experience feel sluggish. I suspect it's just because the animation is too long.

The constant you're looking for is kConstantDuration in cc/animation/scroll_offset_animation_curve.cc.  The tradeoff is that a faster animation will seem jumpier during slow wheel movements.

[Peter Kasting]

Given that we're coming from a world of instantaneous scrolling, we should probably err on the side of making the animation faster for now; we can always tune it to be slightly slower later if we think it makes things visually nicer without significant negative consequences, but if we ship something that's at all too slow at the start, there's going to be a huge outcry.

It looks like today you've set the duration to 1/5th of a second, which definitely seems too long to me.  Can we try cutting that in half to begin with?

PK

[Matt Giuca]

On Fri, 8 Jan 2016 at 10:27 Steve Kobes <sko...@chromium.org> wrote:

On Thu, Jan 7, 2016 at 3:16 PM, Matt Giuca <mgi...@chromium.org> wrote:

+1 to making it scroll faster (maybe 2x the current speed).

(Is there a constant in the source code I can play with to experiment with different speeds?)

I tried this yesterday and found that it feels "nice" (as in, it appeals to me aesthetically), but it made the whole browsing experience feel sluggish. I suspect it's just because the animation is too long.

The constant you're looking for is kConstantDuration in cc/animation/scroll_offset_animation_curve.cc.

Thanks.

OH YEAH. Changed it from 12.0 to 6.0. Now it feels tight. It feels as snappy as it used to, but there is a subtle scroll animation. I would be in favour of halving the duration.

 

The tradeoff is that a faster animation will seem jumpier during slow wheel movements.

I noticed that too, particularly when jumping long distances (with PgDn) it felt too jumpy. On the 12.0 (current) build, PgDn feels lovely. Perhaps the formula for deciding the duration needs to be tweaked. (I see there is already logic to decide the duration based on the size of the scroll, maybe it needs to be faster for shorter scrolls but can stay as long as it is now for longer scrolls.)

To avoid discussing these details here, I opened a bug: http://crbug.com/575409.

[Steve Kobes]

Hi Adam, I've also replied on the bug but here are some general points:

- The smoothness of the animation will naturally depend on your hardware being able to push new frames fast enough.

- Regardless of the frame rate, the animation will not continue to run past its "deadline" measured from the time the input event is handled by the renderer.  (It's not as if we're queueing up a backlog of intermediate scroll positions.)

- There's no "sampling" in the velocity matching as you suggest.  The velocity is calculated as an explicit function of the input time and the curve parameters.

On Wed, Feb 3, 2016 at 7:52 AM, Adam Goode <ago...@chromium.org> wrote:

I suspect the current implementation has some sensitivity to machine performance, which makes it inconsistent between different machines. On slower machines (chromebook flip), scrolling is very hard to control but on my chromebox it is quite nice.

The previous Chrome OS implementation worked very well on all my machines. This would suggest to me that there are some performance-sensitive velocity calculations that were introduced. It could be related to clock or device sampling rates as well.

Can someone take a look at https://code.google.com/p/chromium/issues/detail?id=570549 and tell me if I'm correct in my reasoning?

Thanks,

Adam

[Steve Kobes]

+sullivan

Annie do you know if we have perf tests that simulate mouse wheel scrolling?  If they are picking up the default flags they should be exercising the smooth scroll paths.

On Wed, Feb 3, 2016 at 12:32 PM, Adam Goode <ago...@chromium.org> wrote:

Thanks.

Do we have a perf test that exercises the new code? I would like to see if I can find some differences between devices.

Adam

[Timothy Dresser]

There are a bunch of telemetry tests that perform "mouse wheel" scrolling, though the deltas we send likely look more like touchpad.
Are we still using some delta based heuristic to determine if we should smooth scroll? If so, it's possible that we aren't hitting the smooth scroll pathway in those test cases.

On Mon, Feb 8, 2016 at 7:53 AM Tim Dresser <tdre...@google.com> wrote:

There are a bunch of telemetry tests that perform "mouse wheel" scrolling, though the deltas we send likely look more like touchpad.
Are we still using some delta based heuristic to determine if we should smooth scroll? If so, it's possible that we aren't hitting the smooth scroll pathway in those test cases.

[Steve Kobes]

On Mon, Feb 8, 2016 at 4:55 AM, Timothy Dresser <tdre...@chromium.org> wrote:

There are a bunch of telemetry tests that perform "mouse wheel" scrolling, though the deltas we send likely look more like touchpad.
Are we still using some delta based heuristic to determine if we should smooth scroll? If so, it's possible that we aren't hitting the smooth scroll pathway in those test cases.

Smooth scrolling is not conditional on delta, but it is conditional on the value of WebInputEvent::hasPreciseScrollingDeltas.  There are various platform-specific paths by which this bit is set when constructing this event.

[Miguel A. Vallejo]

Please, please, please.

Disable smooth scrolling by default or add a user setting control to disable it.

Many of us really *hate* those smooth movements: they make us sick affecting our productivity.

Thank you.

[Sunny Sachanandani]

You should be able to disable it using chrome://flags/#smooth-scrolling.

--

[Miguel A. Vallejo]

Thank you for the Quick response.

I'm afraid being a flag, it could be removed in any moment making impossible to people like me to disable it.

Please, just a checkbox in the user settings area. That will be just fine.

Thank you in advance.

[Peter Kasting]

On Wed, Mar 2, 2016 at 1:36 PM, Sunny Sachanandani <sun...@chromium.org> wrote:

You should be able to disable it using chrome://flags/#smooth-scrolling.

Not forever.  We will be removing that flag within a few versions.

It would be good to know what about the movement produces feelings of sickness.  We'd want to avoid that aspect no matter what.

PK 

[David Bokan]

On Windows, Chrome should respect the system-level setting so you can disable it in Windows. See http://crbug.com/575222 for details.

[seagull production]

I'm glad there exists a flag to disable this and I'll be making great use of it until Google strong-arm us into using it just like they did with their pointless profile switcher button.

To anyone involved in Product Management at Google, please hear me saying that this is a horrible feature and I detest it.

Please include an option not to use it.

[Peter Kasting]

On Thu, Mar 3, 2016 at 5:45 AM, seagull production <mnc...@gmail.com> wrote:

To anyone involved in Product Management at Google, please hear me saying that this is a horrible feature and I detest it.

Saying something is horrible tells us nothing about what the problem is.  Precise, careful feedback on exactly what use cases are harmed by this would be an example of actionable feedback.

PK 

[Matt Giuca]

FYI, there was some discussion on Reddit about this:

https://www.reddit.com/r/chrome/comments/48oahd/the_chrome_team_is_delighted_to_announce_the/d0le3oh

(I responded a little but didn't make any promises.) No real concrete feedback here, but at least it helps us judge sentiment.

I know we don't like settings, but I think this may be one of the rare cases where it comes down to user preference and we could slip in a checkbox under "Device". We probably should respect the user's OS setting in Windows and that means we probably should have our own setting on other platforms.

On the other hand, maybe this is just something users have to get used to and we would prefer everyone to be using the same setting on it (and perhaps we still need to tweak the algorithm so it is a bit snappier).

[Peter Kasting]

On Thu, Mar 3, 2016 at 4:51 PM, Matt Giuca <mgi...@chromium.org> wrote:

I know we don't like settings, but I think this may be one of the rare cases where it comes down to user preference and we could slip in a checkbox under "Device". We probably should respect the user's OS setting in Windows and that means we probably should have our own setting on other platforms.

AFAIK we do currently respect the user's OS setting on Windows.  I would be surprised if that's the only OS with a setting controlling animations or the like that we should piggyback off, but as a Windows user I don't know for sure.  If there are indeed such settings on other platforms, we should definitely respect them -- people should give feedback or file bugs to that effect.

On the other hand, maybe this is just something users have to get used to and we would prefer everyone to be using the same setting on it (and perhaps we still need to tweak the algorithm so it is a bit snappier).

We may very well need further algorithm tweaks.  This is part of why I'm keen on people sharing feedback in as great of detail as possible.  A general "we don't like it" tells us little, but if we can experiment with timings and get specific feedback, hopefully we can find a configuration that works well for everyone.

I definitely don't think just punting this to a setting is good.  We're unlikely to make any algorithm improvements after that point since everyone frustrated by the current algorithm can simply turn off smooth scrolling entirely.

PK

[Steve Kobes]

On Thu, Mar 3, 2016 at 5:12 PM, 'Peter Kasting' via input-dev <inpu...@chromium.org> wrote:

AFAIK we do currently respect the user's OS setting on Windows.  I would be surprised if that's the only OS with a setting controlling animations or the like that we should piggyback off, but as a Windows user I don't know for sure.  If there are indeed such settings on other platforms, we should definitely respect them -- people should give feedback or file bugs to that effect.

We currently respect OS settings on Windows (Performance Options > Visual Effects > Animate controls and elements inside Windows) and Mac (NSScrollAnimationEnabled).  I'm not aware of any equivalent on Linux.

[Matt Giuca]

I can't find any settings in the main Ubuntu settings panel for this sort of thing. Interesting; I didn't know we respected Windows' setting (and a bunch of people are complaining that we don't; I guess they should try it). But as I said, I think that if we do respect that OS setting then we should provide our own setting on other OSes (Linux and Chrome OS), for parity.

[Peter Kasting]

On Thu, Mar 3, 2016 at 5:49 PM, Matt Giuca <mgi...@chromium.org> wrote:

I can't find any settings in the main Ubuntu settings panel for this sort of thing. Interesting; I didn't know we respected Windows' setting (and a bunch of people are complaining that we don't; I guess they should try it). But as I said, I think that if we do respect that OS setting then we should provide our own setting on other OSes (Linux and Chrome OS), for parity.

Providing this setting on Linux/CrOS only has all the costs of providing it everywhere but with fewer of the benefits.  That said, I could see an argument for providing this in the general CrOS settings just because the distinction between OS and browser is fuzzy.  Although it would be nice if any such setting we provided were more general than just scrolling, and we understood the accessibility, performance, or whatever else reasons why we felt this was necessary to provide.

I think the complaints that we don't respect Windows' setting might be due to version differences.  My guess is that that didn't get merged to Chrome 48, so stable users weren't seeing it.  I don't know if it got merged to 49.

PK

[Rick Byers]

Smooth scroll is only on by default in M49, and yes the CL to honor the Windows OS setting landed in M49.  So anyone with smooth scroll enabled by default should have it.  Note though that the setting doesn't take affect in existing renderers (need to open a new tab or restart the browser).  If that's not the case then we should file a bug with repro steps if possible (others have confirmed that the setting does indeed work for them).

PK

[Yash Malik]

I just verified on a bunch of Windows machines (running Win7/8/10) that we do in fact respect the OS setting in Chrome M49. I agree that we need a better plan to disable / enable smooth scrolling and knowing exactly what the users like/dislike about the current implementation will help.

[Steve Kobes]

On Fri, Mar 4, 2016 at 4:43 AM, Jacob G <kurte...@gmail.com> wrote:

Can we also discuss another thing: Why are we discussing these things now (post launch!) and not before launch?

We discussed them before launch, and now we are discussing them again.

"Smooth scrolling should respect OS" - nope, denied as too confusing or so.

Where did that happen?

[Peter Kasting]

On Fri, Mar 4, 2016 at 9:33 AM, Jacob G <kurte...@gmail.com> wrote:

My bad. I've only read the reply from the UI team which was against the "respect OS". I've missed the reply afterwards (crbug.com/575222 and the commit). :-)

I don't even see that reply -- comment 12 on that bug is talking about not wanting a separate option, but is not opposed to respecting the OS setting.  (It's trying to accommodate a user who doesn't want us to unconditionally respect the OS setting.)

 

The other point: I mean especially with smooth scrolling, which has been in other browsers for ages (see Firefox) or various available extensions, you could have seen that an option is necessary as certainly not everyone has enabled that option. 

It's true that classically e.g. Firefox has provided an option for this.  OTOH, Firefox has a fairly different design philosophy from Chrome when it comes to options.  More importantly, we think that the majority of complaints about other smooth scrolling implementations are due to them adding too much lag to scrolling; if we can keep lag minimal in our implementation, the hope is that it will be good enough that we have less need for an option.  (That doesn't mean _no one_ will be left wanting an option, but if we can at least keep the number in the same ballpark as the number of people who want options for each of our other UI decisions, that'd be good enough.)  So far, to me, this is proving reasonably true -- the noise about smooth scrolling has been far, far less than I believe it would have been with a bad implementation.

That doesn't mean the current system is perfect.  We've already tweaked the animation curves some in response to developer feedback, I imagine we'd be willing to tweak them further if we get some solid proposals/rationale to do so.

PK

[Sunny Sachanandani]

I think we should treat smooth scrolling as a special case because it's an accessibility issue. People are literally getting sick because of it.

--

[Peter Kasting]

On Fri, Mar 4, 2016 at 11:39 AM, Sunny Sachanandani <sun...@chromium.org> wrote:

I think we should treat smooth scrolling as a special case because it's an accessibility issue. People are literally getting sick because of it.

If it's truly an accessibility issue it may warrant its own option, but I'm not yet convinced it actually is.  I don't mean to discount user reports, but without any idea of why smooth scrolling ought to be able to cause sickness when normal scrolling doesn't (especially when for some types of scrolls we use the same method for both), it's hard to know what to make of the one report I've heard thus far.  It's also not clear why that isn't covered, on the platforms that have most of our users, by the aforementioned system settings for this -- presumably someone made sick by smooth content animations will have turned them off systemwide.

PK 

[Roc Vallès]

On Friday, 4 March 2016 02:54:07 UTC, Yash Malik wrote:

I agree that we need a better plan to disable / enable smooth scrolling and knowing exactly what the users like/dislike about the current implementation will help.

Smooth scrolling does introduce lag, which degrades the UX.

By experience, when I press a key to scroll, it's because I already want the page scrolled; it's bad enough that I already have to wait for my finger to press the key and the computer to react. Please do not introduce any extra lag by forcing the user to watch an animation.

[Sunny Sachanandani]

Based on my observations smooth scrolling is worse on keyboard scrolling than with mouse/touchpad scrolling e.g. if you hold down the down arrow key you'll notice janky scrolling. Scrolling with the touchpad on my macbook OTOH is not janky.

I think this has to do with the key repeat rate being less than refresh rate and key events not being aligned with vsync. I think our key event handling could be improved, we should be generating synthetic scroll events at vsync (begin frame) for the entire duration between a keydown and the corresponding keyup event if we're not already.

--

[Adam Goode]

I have used smooth scrolling for many weeks but finally had to disable it on my Minnie today. I am running on dev channel. A few thoughts:

- Most of my scrolling is with a mousewheel on Chrome OS.

- Over time, I believe I have acquired smooth scrolling fatigue. I think this is something to be aware of, and was discussed here: https://plus.google.com/+KentonVarda/posts/XYT4pA1xKJb

- On my hardware, smooth scrolling is tolerable only on optimally scrolling pages (plain text files or plain HTML files). If a page is at all slow to scroll, smooth scrolling with a mousewheel amplifies this in such a way that makes it intolerable. I never feel this when I am doing keyboard smooth scroll, or scrollbar-click smooth scroll. Direct manipulation scrolling (dragging the scroll thumb or using a touchpad or touchscreen) is always ok as well. Is there a performance problem to be solved?

- My suspicion is that direct manipulation scrolling and (to a lesser extent) keyboard scrolling have predictable eye-tracking outcomes that don't lead to fatigue, but the tricky acceleration curves on mousewheel scrolling are unintuitive and do lead to fatigue. Moreover, the clicking, single-direction feel of the wheel leads me to expect an instantaneous step on the screen, whereas keyboard pressing is more slow (average of 90 milliseconds = 5 screen frames, by http://www.cs.cmu.edu/~keystroke/#sec2), allowing time for animation to occur.

- It also sounds like smooth scrolling needs better integration with keyboard repeat and delay.

My suggestion is that we definitely need to measure and account for smooth scrolling fatigue before we enable it for everyone for all time. And I fear that mousewheel smooth scrolling will never work quite right, even though keyboard-based and mouseclick-based smooth scrolling may end up working very well.

Adam

[Peter Kasting]

Sunny and Adam, your latest pieces of feedback are fantastic, and I would definitely suggest filing bugs for the issues you notice.

PK

[Will Shackleton]

Just to let everyone know, I also recently added high resolution scrolling support to Linux: https://codereview.chromium.org/688253002/ (what I refer to in that CL as "smooth scrolling")

This is related and also happened to get launched in Chrome 49 so for Linux users there are actually two things that changed in this release (high resolution input for supported devices and interpolated movement).

Best,

Will

On Wednesday, 6 January 2016 23:12:39 UTC, Steve Kobes wrote:

Smooth scrolling is enabled at r367942, and will ship with M49 unless we discover new issues.

Smooth scrolling animates a scroll position in response to discrete scroll input, such as "stepped" mouse wheels or keyboard arrows.  For more info on what smooth scrolling entails and how various platforms are affected, see the doc at bit.ly/smoothscrolling.

This resolves a long-standing feature request in crbug.com/575.

If you experience problems with smooth scrolling, please file a bug (crbug.com/new).  You can disable smooth scrolling in about:flags, though this option may be removed in the future.

Happy scrolling,

Steve

[Adam]

I commented at https://bugs.chromium.org/p/chromium/issues/detail?id=583673 with a proposal and some data I collected.

Adam

[Alan deLespinasse]

I really hope the option to disable doesn't go away. But if it does, I guess it should be possible to write an extension to disable it? Just as there were extensions to enable it before it was built-in? I'm not sure, it seems like that might require access to the speed variable, which I think is compiled into Chrome.

On the other hand, now that smooth scrolling exists in all major browsers, maybe nytimes.com will disable their own, slower, JS-based smooth scrolling. Maybe someone here has contacts at the NYT and can request that?