Smooth scrolling algorithm change (Re: KDE/kdelibs/khtml)

[Germain Garand]

Le mercredi 28 mai 2008, Allan Sandfeld Jensen a écrit :
> SVN commit 813615 by carewolf:
>
> The logarithmic slowdown of smooth scrolling violated the total
> scrolling-time and number of steps. Replace it with a square
> (constant deaccelation) slow-down, that still respect the total
> scrolling time, and add some sanity for very small or very large
> scrolling distances.

Hi Allan,

I'm sorry but I really dislike this change. It dramatically changes the 
feeling, and in not so nice a way.
It's not clear to me why you felt it was needed, so I'll give you a full view 
of my approach to this feature - please tell me what exactly you feel is 
wrong with it.

First, there is no violation of "total scroll time", because that configurable 
value no longer represents a total scroll time, which is not attainable nor 
desirable at all as I explain below.

Instead, it is just a magic number, related to time, but not constrained to 
it, giving (through division by delay) a minimal number of frames, to which a 
variable number of braking steps are freely added (the progression from n 
frames to one in bisected steps).

The purpose of such a floating maximal value is to allow the slowing down to 
take place slightly proportionally to the extent of the scrolling.

In other words, it gives a slight feeling of inertia proportional to the 
maximal speed of the smooth scrolling. I think this is a very important 
aspect, as it conveys a feeling of moving something physically, like some 
sort of wheel.

There is no strict time constraint because the speed is, in effect 
rendering-bound, so you can't guarantee a total time at all for one atomic 
scrolling (see example 2bis vs. 3bis below).
Besides, as the algorithm is commonly reentered on additional wheel events,
there is no possibility of defining a total scrolling time as perceived by the 
user (since you will be in effect adding several 'total scroll times' in one 
complete scroll anyway.)

There are other aspects I dislike in the changed algorithm, such as the added 
complexity, and the introduction of an acceleration value. 
I think acceleration is satisfyingly taken care of by the rentrance itself - 
with wonderful simplicity.

Here are two examples of vertical pixel progressions with the previous 
algorithm version to show what I mean; the first is a single wheel event, the 
second a serie (a full "rolling" of the mouse wheel):

1)
 :setupSmoothScrolling: Smooth scrolling starting for  -80 vertical pixels
 :scrollTick: -10
 :scrollTick: -10
 :scrollTick: -10
 :scrollTick: -10
 :scrollTick: -10
 :scrollTick: -10
 :scrollTick: -10
 :scrollTick: -5
 :scrollTick: -3
 :scrollTick: -2
 :scrollTick: Elapsed:  150

2)
 :setupSmoothScrolling: Smooth scrolling starting for  -80 vertical pixels
 :scrollTick: -10
 :scrollTick: -10
 :scrollTick: -10
 :setupSmoothScrolling: Reentered for more  -80 vertical pixels
 :scrollTick: -16
 :setupSmoothScrolling: Reentered for more  -80 vertical pixels
 :scrollTick: -24
 :setupSmoothScrolling: Reentered for more  -80 vertical pixels
 :scrollTick: -31
 :setupSmoothScrolling: Reentered for more  -80 vertical pixels
 :scrollTick: -38
 :setupSmoothScrolling: Reentered for more  -80 vertical pixels
 :setupSmoothScrolling: Reentered for more  -80 vertical pixels
 :scrollTick: -52
 :scrollTick: -53
 :scrollTick: -53
 :scrollTick: -52
 :scrollTick: -53
 :scrollTick: -52
 :scrollTick: -53
 :scrollTick: -27
 :scrollTick: -13
 :scrollTick: -7
 :scrollTick: -3
 :scrollTick: -2
 :scrollTick: -1
 :scrollTick: Elapsed:  300

This is with timings 120/15 = 7 frames + 1 frame (divided in n braking frames)

example 1) shows how the smallest scroll only results in 3 braking frames 
being added in an otherwise constant movement. 7 + 3 = 10 frames, which is 
the exact number that was used before the braking code addition.

as can be seen in 2), the mere reentrance is providing exactly the 
acceleration we are looking for with a serie of 10-10-10-16-24-31-38-52

the braking now happens in 6 frames, which is consistent with the large 
movement but not distracting or overdone.

For comparison, here are the numbers given by the algorithm after your 
changes:

1 bis)
:setupSmoothScrolling: Smooth scrolling starting for  -80 vertical pixels
:scrollTick: -16
:scrollTick: -16
:scrollTick: -16
:scrollTick: -16
:scrollTick: -16
:scrollTick: Elapsed:  62

This is with timings 150/15, which should be ten frames but ends up at 5, in 
less than half the 'total scroll time', and without any slowing down.

2 bis)
setupSmoothScrolling: Smooth scrolling starting for  -80 vertical pixels
:scrollTick: -16
:scrollTick: -16
:scrollTick: -16
:setupSmoothScrolling: Reentered for more  -80 vertical pixels
:scrollTick: -22
:scrollTick: -22
:setupSmoothScrolling: Reentered for more  -160 vertical pixels
:scrollTick: -46
:setupSmoothScrolling: Reentered for more  -80 vertical pixels
:scrollTick: -52
:scrollTick: -53
:setupSmoothScrolling: Reentered for more  -80 vertical pixels
:scrollTick: -47
:setupSmoothScrolling: Reentered for more  -80 vertical pixels
:scrollTick: -54
:setupSmoothScrolling: Reentered for more  -80 vertical pixels
:scrollTick: -59
:scrollTick: -59
:scrollTick: -59
:scrollTick: -59
:scrollTick: -60
:scrollTick: Elapsed:  180

and now a 3rd example, of a smaller wheel movement than in 2 bis), but on a 
different, more complex site, showing how the difference in rendering speed 
affects dramatically the timings anyway:

3 bis)

:setupSmoothScrolling: Smooth scrolling starting for  -160 vertical pixels
:scrollTick: -32
:scrollTick: -32
:setupSmoothScrolling: Reentered for more  -80 vertical pixels
:scrollTick: -36
:setupSmoothScrolling: Reentered for more  -80 vertical pixels
:setupSmoothScrolling: Reentered for more  -160 vertical pixels
:scrollTick: -76
:scrollTick: -76
:scrollTick: -76
:scrollTick: -76
:scrollTick: -76
:scrollTick: Elapsed:  250


from my pov this clearly shows the previous algorithm is much preferable,
providing a smoother, natural effect, achieved with greater simplicity and 
robustness.

Greetings,
Germain