Rockbox General > Rockbox General Discussion

iPod 5.5G scrollwheel responsiveness - any work being done?

<< < (3/3)

Zardoz:
fair enough. (i wish i had a gigabeat  :-\)
what i meant was if, like you say, the code used for updating menu lines is slow and the screen  itself is slow, why is it (responsiveness) only sometimes an issue? that's all. anyway thanks for replying. and thanks for developing such a cool piece of software. i hate to niggle. (i used rockbox on my X5 for years until it was stolen. it was only when i got an ipod i was 'forced' to post annoying questions here and hereabouts. how bout them apples??)

nicke2323:
Original poster here, sorry for the delay in getting back. I just spent some time comparing scrolling in the iPod firmware with Rockbox in lists of identical lengths. My conclusion:

I actually prefer the scrolling dynamics in Rockbox to those in the original firmware. The main problem with Rockbox is that there is a slight delay after I stop scrolling until the cursor stops. The delay is only a fraction of a second or so, but that is enough to cause the cursor to consistently overshoot the target, no matter the scrolling speed (a slow speed only overshoots by one step, faster speeds by several steps). The constant need for scrolling back after overshooting is what makes the scrolling feel clunky.

I'd like to try the CPU boost patch to see of that reduces the stop delay, but have no way of compiling Rockbox at the moment.

EDIT:

Soap (one of the moderators) was kind enough to compile and send me the latest SVN version with the CPU boost patch. I am glad to report that this eliminates the stop lag completely. Scrolling now feels just as responsive as the original iPod firmware. I feel it accelerates smoother as well, but that may just be a placebo.

Two questions:

1. Can the code be improved to reduce the lag without the CPU boost patch?
2. Alternatively, can the CPU boost patch be committed?

Llorean:
1) Possibly, and we're hoping to investigate that.
2) Almost certainly, but if it is, it reduces the possibility of more research time spent on 1. That being said, if we do a 3.0 release, the release version will probably have the patch (assuming no problems crop up with it) while the development version will probably continue not to for a while so that the signs of further optimizations are more obvious, at least until we're sure the lag won't go away so easily.

Buschel:
Regarding the CPU boost patch: I am not sure it will be committed as lots of testing is needed -- especially to check effects on plugin behaviour (like games). The patch boosts the CPU on each scrollwheel activity, independent of the GUI context.
Maybe another interim solution (e.g. only boosting when GUI is in list context) must be found...

Navigation

[0] Message Index

[*] Previous page