Rockbox General > Rockbox General Discussion

Why the ipod 4G/5G scroll acceleration patch is jumpy, and how you might fix it

<< < (3/3)

Llorean:
Yeah, sorry about that. I'd read your post on a portable device, and probably managed to accidentally jump past your mention of the safeguard, then came back later to type a response I'd kept in my head without re-reading the post.

Flid:
I wasn't going to jump in to this thread, as I didn't want to veer it in another direction... but Toxikator already did that for me.

TPD / Senab. Would your patch work with a REAL acceleration, rather than stepped speed increases?

Wouldn't it be more sensible to make this cross-platform? Could you have a variable acceleration in the same way that FFWD works with button presses in WPS (ie. a user adjustable of 2x scroll speed after 1/2s, 1s, 2s, 3s etc)?

This way, you could have Rockbox just recognise the fact that you were scrolling (regardless of speed of scroll) and then accelerate per second of continued action. This would obviously allow for cross platform usage (where as scrollwheel speed is purely restricted to iPod & Sansa).

Obviously, getting to the end of VERY long lists may take a bit longer, but you wouldn't need to train your fingers to a speed of rotation, just learn how quickly the acceleration builds up (IMHO quite intuitive?!?!).

You may have discussed this at length when you started working on your patch in the first place, so I apologise if this is brining up an old subject.

TP Diffenbach:

--- Quote from: Toxikator on May 07, 2007, 12:16:04 PM ---8600 items, yes, but not for most users. Because most users in Tagcache have things ORGANIZED.

8600 songs? Maybe, if you feel some sort of silly urge to browse your entire collection song at a time. Take those 8600 songs and divide them up into maybe 800 Albums. 800 albums into maybe 600 artists or 20 genres. Those are the lists people work with.

--- End quote ---

Well, maybe I am disorganized and silly, but it's my patch and my time and my analysis.

I agree, there should be a number of different ways to handle scroll acceleration (see my scroll accel API patch, which attempts to give a common API all implementations might use). If you think you have a better way to do it, fork my code or start from scratch.

TP Diffenbach:

--- Quote from: Flid on May 07, 2007, 05:04:40 PM ---TPD / Senab. Would your patch work with a REAL acceleration, rather than stepped speed increases?

--- End quote ---

Short answer: yes, in theory. No, according to the tests I've done.

In theory, we should be able to determine the "instantaneous" scroll speed at  any time, and scroll according to that. The problem is that screen updates take a non-trivial amount of time. In fact, by the time we've done one scroll update, the scroll wheel interupt will have fired multiple times.

What I do now (I think -- it's been a while since I wrote the code) is calculate the average speed since last screen update. This could be improved -- I think --, particularly by determining if the user is speeding up or slowing down.

But the other problem is that the user really can scroll faster than we can read the scroll and update the screen. I made several cheap kludgey attempts to average and "dampen" that, but never found anything that worked real well. I would really appreciate any suggestions anyone has for doing that better.

But the best things I found were outside of the scroll per se. That's why the original patch also included list display optimizations, of two sorts (when the page changes, and when the page does not). I believe those chnages are made obsolete by other changes to the list code.

I also rewrote the screen update code in ARM assembly. But I never submitted that patch, because it does no real good. While it was intrinsically considerably faster than what we had at the time, the improvements were completely swamped by the need to sleep the screen update until the broadcomm chip is ready for the next screen update. (The root problem is that our screen update code is based on a broadcomm firmware debug function, not on the (presumably much faster) way Apple updates the screen. Fast code + long wait isn't any faster than slower code   + long wait.

Then I rewrote memcpy in ARM, because the list functions use it. That did produce a speed improvement, but events intervened and I wasn't able to submit that. (see http://www.rockbox.org/mail/archive/rockbox-dev-archive-2006-07/0005.shtml    )

So basically, yes, there are a number of improvements that can be made to scrolling, but considerable trial and error is involved. If you browse the mailing list, you may be able to find some of my findings on these subjects.

Your ideas are good and I encourage you to explore them, as you'll probbaly see something I missed.

Navigation

[0] Message Index

[*] Previous page