Rockbox General > Rockbox General Discussion

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

<< < (2/3) > >>

CpuWhiz:
I was going to look into this but you beat me to it senab, so I will just go and explain the menu system some in case you want some help deciphering it. The line that creates the menu is in apps/menus/settings_menu.c and looks like this:


--- Code: ---MENUITEM_SETTING(ipod_scroll_wheel_acceleration_fast, &global_settings.ipod_scroll_wheel_acceleration_fast, NULL);
--- End code ---

The first argument is the actual variable that holds the value the user defined, this can be found in apps/settings.h. The next one is a reference to the structure that holds the setting (doesn't need to be changed). The 3rd is the same as the 1st, maybe one is the default value and the other is where to store it, not quite sure. The last is NULL and I have no clue what it does ;D

Then we move on to apps/settings_list.c:


--- Code: ---INT_SETTING(0, ipod_scroll_wheel_acceleration_fast, LANG_IPOD_SCROLL_WHEEL_FAST, 135,
         "ipod scroll wheel fast threshold in clicks/sec", UNIT_SEC,
         5, 500, 5,
         NULL, NULL, NULL),
--- End code ---

ipod_scroll_wheel_acceleration_fast is our variable again. LANG_IPOD_SCROLL_WHEEL_FAST matches a entry in apps/lang/english.lang. The 135 is the default value and the 5, 500, 5 is the minimum value, the maximum value, and the increment between each option in the menu. UNIT_SEC is the "s" that gets added to the options in the menu. Maybe try UNIT_PERCENT. The text is a fall back for the menu name (since we only define the English translation for the menu this is what would show up for other languages). Again, the NULLs I have no clue about. I picked up the menu system from looking at some other menu entries. I don't find it too difficult and I hope you don't either. Good luck senab! I love your builds!

Edit:
Almost forgot, you need to then add the entry to the actual menu:

--- Code: ---MAKE_MENU(ipod_scroll_wheel_acceleration_menu, ID2P(LANG_IPOD_SCROLL_WHEEL_SPEED), 0, Icon_NOICON,
          &ipod_scroll_wheel_acceleration_fast,
          &ipod_scroll_wheel_acceleration_faster,
          &ipod_scroll_wheel_acceleration_fastest,
         );
--- End code ---

Now that I think about it, one of the two ipod_scroll_wheel_acceleration_fast variables above is a local variable for the menu setting and &ipod_scroll_wheel_acceleration_fast is the reference to it that adds it to the main scroll menu. Hope that helps.

ryran:
It's so cool to see that all of TP's work on this isn't going to be abandoned. Yay.

Toxikator:
Maybe I'm missing the point but wouldn't it be smoother/more accurate to jump by lines?

As in, at "normal" one click is one menu line

At "fast" one click is two menu lines (2x)

At "faster" one click is three menu lines (3x)

At "fastest" one click is four menu lines (4x).

Or something like that, with 2x, 4x, 8x, etc.

Seems like it would a) be FAR more consistent and b) not so jumpy since you WONT move from slow scrolling to a few pages down.

TP Diffenbach:

--- Quote from: Toxikator on May 05, 2007, 08:46:24 AM ---Maybe I'm missing the point but wouldn't it be smoother/more accurate to jump by lines?

As in, at "normal" one click is one menu line

At "fast" one click is two menu lines (2x)

At "faster" one click is three menu lines (3x)

At "fastest" one click is four menu lines (4x).

Or something like that, with 2x, 4x, 8x, etc.

Seems like it would a) be FAR more consistent and b) not so jumpy since you WONT move from slow scrolling to a few pages down.

--- End quote ---

Because it would be too slow. The most "clicks" we can get in one revolution of the dial is 24 (there are 96 positions, but we don't count any movement less than 4 clicks, to suppress jumpiness.)

Our lists (using my numbers, in the database) range from as little as 60 items, to as many as 8600+. True, this is different if you're using directory browsing, but I suspect most ipod users find directory browsing useless.

At 8 lines per scroll, we'd get a maximum of 192 lines per dial; even assuming the user remembers to browse backwards when he knows the target item is in the second half of the list, he needs to be able to go at least  4400 lines, or more than 22 revolutions. This is tedious.

Plus, we wouldn't get really get 192 lines per dial, as the list refresh takes time, during which sending keys is blocked.

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page