Annouce: patch to speed up SOME list scrolling by a factor of ~12
A patch to optimize 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 HeightAverage Unoptimized Average Optimized Ratio of Unoptimized/Optimized 5 123039.71 4555.51 27.01 7 128322.65 15404.248.33 14 116112.13 7363.98 15.77 16 128704.18 8046.00 16.00 24 130604.73 20603.506.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 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: gui_list_opt AT diffenbach.org Note that a peculiarity of tagcache makes this a bit more complex than it would otherwise be; tagcache uses the same gui_list structure for ALL its lists. The patch can be found on the patch tracker, here: http://www.rockbox.org/tracker/task/5591 Thanks.
recording monitoring issue on some h1x0 players
amiconn, preglow: I'm unable to spend time on this issue, maybe one of you can check it out? The problem seems to be that when using the option that rockbox boots into the recording screen, there is no audio monitoring possible until you leave and re-enter the recording screen. related links: http://www.rockbox.org/tracker/task/5589 http://forums.rockbox.org/index.php?topic=2513.330 original message from Alan Martello: By repeatedly checking out versions from CVS and doing builds, I was able to determine that the build on 2006-05-12 works but the build on 2006-05-13 does not. Upon diff-ing the source trees, I find the following files have changed. In apps: debug_menu.c, settings.c, sound_menu.c In firmware: pcm_record.c The changes in debug_menu.c, settins.c and sound_menu.c were fairly minor and didn't appear to be the culprit at first glance. The changes in pcm_record.c however is another matter. 2006-05-13 was when substantial SPDIF recording changes were checked into pcm_record.c To see if I could narrow it down additionally, I commented out HAVE_SPDIF_IN, HAVE_SPDIF_OUT and HAVE_SPDIF_POWER in export/config-h120.h, and after fixing a compiler error in debug_menu.c, the resulting firmware still did not output audio to the headphones when started automatically in recording mode. I then looked closer at the diffs of pcm_record.c and I have definite suspicions about the usage of DATAINCONTROL (was used only at init time in the old firmware and is now used a number of times throughout). I couldn't tell for sure if the effected bits in DATAINCONTROL are associated with the headphones or not (it's a lot of information for me to get up to speed on). Anyway, I think I've reached my limit. The sleep(HZ) fix works. My guess is that the rearrangement to pcm_record when SPDIF support was added on 2006-05-13 tweaked some initialization code that was working fine before the change. If you can think of anything else I can look at or have suggestions to test, let me know. Thanks for listening and your suggestions. Alan
Re: Annouce: patch to speed up SOME list scrolling by a factor of ~12
Great! What, I wonder, was the reason for redrawing the entire list when moving the selection bar up/down the screen? - Original Message - From: [EMAIL PROTECTED] To: Rockbox development rockbox-dev@cool.haxx.se Sent: Saturday, June 24, 2006 7:30 AM Subject: Annouce: patch to speed up SOME list scrolling by a factor of ~12 A patch to optimize apps/gui/list.c, function gui_list_draw.
Re: Daily builds and fonts
On Sat, Jun 24, 2006 at 04:18:59PM +0200, Daniel Stenberg wrote: You don't by simply checking the name at least. That I thought. ;-) Couldnt you stop building the font archive if it was not changed? Yes, we *could* but that would only mean more work so I've seen no reason to do it. Hm, could you insert into the fonts field (there the rockbox logo is and the links for latest and old) the date of the last change of the archive? Shade and sweet water! Stephan -- | Stephan SeitzE-Mail: [EMAIL PROTECTED] | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: Daily builds and fonts
On Sat, 24 Jun 2006, Stephan Seitz wrote: Hm, could you insert into the fonts field (there the rockbox logo is and the links for latest and old) the date of the last change of the archive? Not easily, as the script that creates the font archive has no idea about any changes. It just builds an archive and I run that script every day. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Daily builds and fonts
On Sat, 24 Jun 2006, Stephan Seitz wrote: Okay, but within the archive nothing would change, wouldnt it? So if we could add md5sum/sha1sum (which would be a gould idea for every archive, I think), you could check this value. Yeps, we could do that! -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
