Smooth scrolling algorithm change ( KDE/kdelibs/khtml)

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

Hi Germain

Friday 30 May 2008, Germain Garand wrote:
>
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.
>
I think you have missed a lot in how the new algorithm works and how simple it
really is. The integer-calculations with remainder makes it look more
complicated than it really is.

I felt the besected steps was based on a completely different philosophy than
the original scrolling algorithm, and wasn't really compatible.

I also disliked the unnatural feel of the deacceleration. The new algorithm is
based on a pseudo-physical simulation where the page deaccelerates constantly
like a car breaking or a ball rolling.

The main idea in my original implemenation is that after the _last_ touch on
any button there is at most the scrolling time until the animation is
completed. I like to keep this because it adds a feel of responsiveness.
Currently the algorithm needs a timer check so we can add two steps together
instead of trying to render every single step on a slow page.


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.
>
I think it is attainable and desirable.

>
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.

This simplicity is still there. There is just a constant deacceleration, the
rest is still the same. The page accelerates when a button is pressed while
scrolling, and after the last scroll the page animates for a maximum of
scrolling-time.

>
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.
>
This example is wrong. 80 pixels over 5 steps will be animated with starting
speed of 32px/step, and a deacceleration of 32/5 px/².

Besides the number of steps in this case will still be 10, because the average
speed of 8px/step is over 4px/step.

The short-cutting of the total scrolling time will only happen for scrolling
distances of less than 40px, or less than 3 lines of text, that is less than
a one scrollwheel tick, so it won't happen at all right now. I've only added
it to make my experiments with scrolling one line (arrow up and down) look
better.

2nd and 3rd example are equally wrong. Though trying to do this emulation by
hand has made me aware of a small bug that means the scrolling is completed a
little too soon (first step shouldn't be quite 2x average speed).

I really hope we can find something to agree on, but first I think you have
missed a greater part of how my new algorithm works, and I need to fix a bug
so actually takes the last 2 steps in all cases.

Greetings
`Allan

Le vendredi 30 mai 2008, Allan Sandfeld Jensen a ©crit :
Hi Germain
>
Friday 30 May 2008, Germain Garand wrote:
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.
>
I think you have missed a lot in how the new algorithm works and how simple
it really is. The integer-calculations with remainder makes it look more
complicated than it really is.
>

hmm, then visibly, what I'm missing is something that actually work as you
describe (I'd love to try it).

Problem is: it doesn't. I didn't made up the numbers, they are what's produced
here when applying some simple instrumentation with the attached patch, and
using the mouse wheel.

The result has changed slightly with your addition of today (I now see one
slowing down step), but it still doesn't match you description at all:

setupSmoothScrolling: Smooth scrolling starting for -80 vertical pixels
scrollTick: -14
scrollTick: -15
scrollTick: -14
scrollTick: -15
scrollTick: -14
scrollTick: -8
scrollTick: Elapsed: 85

Any idea what's wrong?
Germain

Friday 30 May 2008, Germain Garand wrote:
Le vendredi 30 mai 2008, Allan Sandfeld Jensen a :
Hi Germain
>
Friday 30 May 2008, Germain Garand wrote:
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.
>
I think you have missed a lot in how the new algorithm works and how
simple it really is. The integer-calculations with remainder makes it
look more complicated than it really is.
>
hmm, then visibly, what I'm missing is something that actually work as you
describe (I'd love to try it).
>
Problem is: it doesn't. I didn't made up the numbers, they are what's
produced here when applying some simple instrumentation with the attached
patch, and using the mouse wheel.
>
The result has changed slightly with your addition of today (I now see one
slowing down step), but it still doesn't match you description at all:
>
setupSmoothScrolling: Smooth scrolling starting for -80 vertical pixels
scrollTick: -14
scrollTick: -15
scrollTick: -14
scrollTick: -15
scrollTick: -14
scrollTick: -8
scrollTick: Elapsed: 85
>
Any idea what's wrong?

Yes, maybe there is a deacceleration bug around 0.5px/step^2, so it only
deaccelerates right for larger distances.

The issue is that for negative values of ddx the remainder calculation might
not work: (x/16)*16 + x%16 = x, maybe only applies for positive numbers of x.

The attached patch should fix it if I am right, but I don't have time to
actually test it myself until monday.

Regards
`Allan