Annouce: patch to speed up SOME list scrolling by a factor of ~12

Rockbox Development > Starting Development and Compiling

(1/3) > >>

TP Diffenbach:
This patch optimizes apps/gui/list.c, function gui_list_draw.

Previously, all lists were always redrawn in their entirety. With this patch, when the list's start position (the item at the top of the list) hasn't changed, only the /lines/ changed are updated. In almost all cases, that means only two lines are updated, the line the cursor is leaving and the line to cursor is moving to. When a list's start position changes, or when a new list is shown, the whole list is re-drawn using the original cvs code.

Provision is made to handle the "pointer" cursor as well as the standard inverted bar cursor.

The speed increase depends on the font used; the smaller the font, the more lines have to be drawn to fill the screen, and so the greater the speed savings. Here's a non-controlled sample of the average speeds of the regular and the optimized list redrawing, in microseconds, for several font sizes, on my Ipod Video (G5, 60GB, using only 32MB of memory, that is, build 15):

Font Height Average Unoptimized Average Optimized Ratio of Unoptimized/Optimized
5 123039.71 4555.51 27.01
7 128322.65 15404.24 8.33
14 116112.13 7363.98 15.77
16 128704.18 8046.00 16.00
24 130604.73 20603.50 6.34

For ipods, there's an often mentioned problem of music play stopping when lists are scrolled. This will not fix the problem, but will alleviate it quite a bit.

Please perform the following experiment before using this patch in a build. Using your current build, play a song, then go to the menu and rapidly scroll up and down the list until the music stops playing. Then try the same using a build with this patch. Then do a logfdump (Menu|Info|Debug|logfdump), and mail the file logf.txt in your device's .rockbox directory to:
rockbox_gui_list_opt AT diffenbach.org

Thanks.

The patch can be found here:
http://www.rockbox.org/tracker/task/5591

TP Diffenbach:
Dave Chapman (linuxstb) notes that the original patch will work only on PP5020 ipods, and only on builds with logf support.

For all other builds, or if you're unsure your build supports the original patch, use this second patch, gui_list.unpaged.optimization.2.patch

Jens Arnold (amiconn) suggests using the patch with paged scrolling on.

Thanks to both!

With or without paged scrolling, I CANNOT on my ipod G5 scroll fast enough to make music skip, even listening to a 320 CBR mp3, so long as the scrolling is WITHIN a page and thus optimized.

Mr. Brownstone:
I get a hunk-failed error when applying the patch, but it can be safely ignored:

--- Code: ---***************
*** 29,35 ****
#include "list.h"
#include "scrollbar.h"
#include "statusbar.h"
- #include "textarea.h"

#ifdef HAVE_LCD_CHARCELLS
#define SCROLL_LIMIT 1
--- 29,35 ----
#include "list.h"
#include "scrollbar.h"
#include "statusbar.h"
+ #include "textarea.h"

#ifdef HAVE_LCD_CHARCELLS
#define SCROLL_LIMIT 1

--- End code ---

The only difference between the two lines is a single trailing space. ;D

aegis:
Nice patch. It proves that actually some people are taking a look into the source and try to improve it a bit. :)

Thanks for the authors and hope to seeing from you soon. :) I hope as well that the best solution will be after some verification included in CVS as soon as possible...

TiMiD:
I didn't applied the patch, but just looking at the source code makes me think this doesn't work for 2 screens devices because of the way you test if a list has to be completely redrawn or just partially (in the case of 2 screens devices, the list will be redrawn each time).

Of course this can be solved easily (maybe an approach where the calling program decides wether it should be completely redrawn or not would offer more flexibility)

Else nice patch :)

Navigation

[0] Message Index

[#] Next page

Go to full version