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

[Allan Sandfeld Jensen]

Hi Germain

On 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/step².

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