Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category User Interface
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.6
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by kugel. - 2010-11-05
Last edited by kugel. - 2010-11-10

FS#11727 - Touchscreen: Improved scroll threshold

This patch changes the hardcoded scroll threshold to be runtime evaluated and DPI-dependant.

It should make list much more usable, especially on high dpi screens.

On Android, it calls the corresponding API. On all other touchscreen I reimplemented Android’s the calculation, so the effect should be about the same.

Closed by  kugel.
2010-11-10 15:27
Reason for closing:  Accepted
Additional comments about closing:  

r28548

apps/gui/bitmap/list.c: s/threshold_accumulation ;/threshold_accumulation;/
firmware/export/config/ondavx767.h: s/this are not/these aren't/ (actually you can just change the LCD_{HEIGHT,WIDTH} to the correct dimensions)
firmware/target/hosted/sdl/lcd-sdl.c: s/direclty/directly/

Haven't actually tested the patch, but looks good otherwise (we should do something about those unchecked JNI calls though, perhaps something like WARN_ON() in Linux kernel?).

Thanks for the typo police :) I'll change it to the correct dimensions as you suggest.

What do you mean with unchecked jni calls? You mean in case GetMethodID failed? I think it can only ever fail if the object couldn't be created, and we call only through jni for object we create in the native layer. There's little point in checking since we're doomed anyway if any of the object instantiation fails.
Or do you mean something else?

This works really nice with the M:Robe. Between this and the Kinetic scrolling it adds quite a bit to the usability of the target, but there is a problem that comes up that I can reproduce in the sim.

I don't think it is specifically related to this patch, but at least the kinetic scrolling work you did happens to make it more pronounced.

If I do a fast swipe across the screen, or keep scrolling continuously eventually the audio drops out until I stop scrolling. It appears that the list handling code is not yielding enough for the audio buffer to stay filled.

On the sim it is harder to reproduce, but if I click on the scroll bar and start moving back and forth on the screen I will get messages like this:
sdl_audio_callback: No Data.

On target it happens pretty quick, just a couple of quick swipes and the audio will drop out.

Well, it does yield, otherwise kinetic scrolling wouldn't work. The movement of the list and the drawing happens from different threads.

Anyway, I had this happen on my phone too but I don't really know how to fix. Decreasing the update rate works but makes the scrolling less smooth

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing