This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11727 - Touchscreen: Improved scroll threshold
Attached to Project:
Rockbox
Opened by Thomas Martitz (kugel.) - Friday, 05 November 2010, 20:34 GMT+2
Last edited by Thomas Martitz (kugel.) - Wednesday, 10 November 2010, 16:27 GMT+2
Opened by Thomas Martitz (kugel.) - Friday, 05 November 2010, 20:34 GMT+2
Last edited by Thomas Martitz (kugel.) - Wednesday, 10 November 2010, 16:27 GMT+2
|
DetailsThis 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, 16:27 GMT+2
Reason for closing: Accepted
Additional comments about closing: r28548
Wednesday, 10 November 2010, 16:27 GMT+2
Reason for closing: Accepted
Additional comments about closing: r28548
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?).
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?
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.
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