FS#11727 - Touchscreen: Improved scroll threshold

Attached to Project: Rockbox
Opened by Thomas Martitz (kugel.) - Friday, 05 November 2010, 19:34 GMT
Last edited by Thomas Martitz (kugel.) - Wednesday, 10 November 2010, 15:27 GMT
Task Type Patches
Category User Interface
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Release 3.6
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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.
This task depends upon

Closed by  Thomas Martitz (kugel.)
Wednesday, 10 November 2010, 15:27 GMT
Reason for closing:  Accepted
Additional comments about closing:  r28548
Comment by Maurus Cuelenaere (mcuelenaere) - Friday, 05 November 2010, 19:45 GMT
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?).
Comment by Thomas Martitz (kugel.) - Friday, 05 November 2010, 19:49 GMT
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?
Comment by Karl Kurbjun (kkurbjun) - Saturday, 06 November 2010, 03:32 GMT
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.
Comment by Thomas Martitz (kugel.) - Saturday, 06 November 2010, 11:33 GMT
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