Rockbox Development > Feature Ideas
faster AA?
saratoga:
--- Quote from: CowonFTW on September 29, 2010, 07:34:43 PM ---
--- Quote from: gevaerts on September 29, 2010, 02:53:26 PM ---No. Reading the relevant part of the manual should be sufficient.
--- End quote ---
Could you please explain this code block from from albumart.c ?
--- End quote ---
Its a comment that lists all the places album art can be searched, same as the ones in the manual. Actually looking at it none of them have the colon in it you mentioned above, nor do the wiki or manual. Where the heck did you get the idea you needed a colon? It should probably be fixed.
--- Quote from: CowonFTW on September 29, 2010, 07:34:43 PM ---I did not make this up, nor write this code, and since the whole point is to lessen the compare interval to it's shortest time possible thought it relevant that it skip the per-file search...
--- End quote ---
I think you should start out trying things a little easier before diving into album art. Once you get the hang of c this will probably make more sense.
dreamlayers:
I don't think that the search is significantly slowing down album art.
Maybe do a test. Comment out the searching, leaving just one option. Maybe even alter the code so there is only one single album art file which is loaded for every album. Then see if things are faster that way.
Llorean:
Wouldn't the problem be the aforementioned "large" images? Just don't put ridiculously large album art on your player with the filename Rockbox is going to look for first, and you don't have to wait for the resize.
Your insistence that Rockbox "co-exist" with the way the original firmware wants files is your problem, not Rockbox's which is, as described, a "replacement" firmware not a "supplemental" firmware.
torne:
--- Quote from: CowonFTW on September 29, 2010, 07:34:43 PM ---since the whole point is to lessen the compare interval to it's shortest time possible thought it relevant that it skip the per-file search..
--- End quote ---
There are two reasons why this doesn't make sense, one of which has already been explained.
1) The search takes probably *microseconds*. I would be surprised if it added up to even one millisecond. So, trying to optimise it is a waste of time.
2) The search is done at the time the track is *buffered*, not when it starts playing. Album art is buffered in advance just like the actual track data, so the search can't be causing a lag at the time it plays.
pabouk:
--- Quote from: saratoga on September 29, 2010, 08:04:50 PM ---Its a comment that lists all the places album art can be searched, same as the ones in the manual. Actually looking at it none of them have the colon in it you mentioned above, nor do the wiki or manual. Where the heck did you get the idea you needed a colon? It should probably be fixed.
--- End quote ---
Saratoga, please read it more carefully, especially the last part of the comment - start on the third line from the end. If I understand it correctly the colon character acts as a switch so it is not a necessary part of a filename with size specified.
Regarding the speed of displaying AA: I think the biggest delay is caused by loading, decoding and displaying the image. This problem could be solved by pre-loading and pre-decoding the next image in advance. I.e. you would have the current image displayed and the next one prepared in RAM. Unfortunately it will require more RAM.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version