The progress callback doesn't rate limit LCD updates, which causes
excessive slowdowns (up to 150x!) on some targets. Limiting updates
to 20fps solves the problem and should boost load speed across the
board, particularly for large images and animated GIFs that may run
the progress callback thousands of times.
Change-Id: Ia48924d4dcb24c1111509329581809be494d0165
In some circumstances it was possible for a bitmap to overflow its
buffer and overwrite the next handle. The easiest way to trigger it
is with a highly compressed JPEG that is decoded to a large bitmap.
Because the JPEG file size is used to determine how much to allocate
this would cause an obvious buffer overflow when the JPEG is smaller
than the decoded bitmap. Fix this by using the decoded bitmap size as
the allocation size. Some overhead must be added to deal with JPEGs,
but it will be freed once the image is loaded.
A less obvious possibility is the fact that add_handle() will allow
a handle to be added even if there's not enough space for the entire
allocation. This is generally beneficial because it allows the first
part of a file to be loaded while waiting for space to free up, but
for bitmaps it is not valid because the whole image is loaded at once.
Hence if there is not actually enough space in the buffer, the bitmap
load can again overflow the actual free space and overwrite the next
handle.
The buffering code supports an H_ALLOCALL flag for allocations that
need the free space available immediately, so use it for bitmaps to
avoid that bug.
load_image() had a sketchy-looking check for free space which stopped
me from triggering the bug with simple tests, but since guessing the
free space is obviously a bad idea when the caller *knows* how much
free space there really is, remove that guess and let the caller tell
load_image() the real deal.
Change-Id: If62a58759705d83c16ee5b50f26bcbccc3f6c01f
JPEG decoding requires additional space in the bitmap buffer beyond
what is needed for the decoded pixel data. Provide a way to estimate
how much overhead is needed.
The actual overhead is sizeof(struct jpeg) + decode_buf_size, where
the latter depends on the image size and JPEG encoding used. From my
testing decode_buf_size is normally pretty small (under 5 KiB) but
looking at the code it could be large in some cases, primarily with
large images, so 32 KiB seems to be a decent compromise. Someone who
knows better about JPEG should pick a better value if that's too big.
Using a constant is obviously not the most accurate but it seems to
be the simplest option for retrofitting to existing code.
Change-Id: I573b0abb8ca2d79e43f185010487f07226edb793
Not sure what the comment is talking about - signed overflow
is undefined behavior and we don't use -fwrapv or other flags
to make it defined. I can't see how a compiler could abuse it
here, but the overflow is nonetheless easily avoided.
Change-Id: Ibed6d7c0d841db2aa86b9d8ba4c6a0d08c413354
don't stop playback to alloc viewports for the keyboard
For the moment it doesn't make much difference
each vp takes about 40 bytes (double that in the sim?)
so not the end of the world 120 extra bytes
Change-Id: I482d7e3061cf9fb8065dc28bf62a6f830770f3c7
While the track number is limited to 99, I know of no documented
constraint on the value of offset minutes to 99.
As we are storing the millisecond offset as unsigned long, assuming
32 bit, we can allow 70,000 minutes (2^32 / 60000).
However, I've been unable to generate a test audio file 48 days long
under 2GB, so I've set the limit to 30,000 minutes.
In addition, this change reduces the maximum number of seconds to 59,
and frames to 74.
I've generated some silent test files with the filenames being
cue_[minutes].mp3
http://peskett.co.uk/rockbox/test_cues/
Change-Id: I3ca4468ebc88ba134c4e785e9395f90bf76941ac
allows items to be moved around with less code changes
remove scrolling I was not overly impressed with it
add test_kbd plugin
Change-Id: Ic183c7221bda9405891632704f3a7bbfd79bfe83
if you skip a track after the halfway point the scrobbler may double post
with slightly different timestamps but the same track info
take a crc of the non-unique part and check against the previously
written track
Change-Id: I676342c4cd76f632131d9cb6d9f7d2f59df357e6
The comment regarding Windows paths was fairly confusing as to
its intent. What the code is trying to do is replace the drive
letter with the volume containing the playlist, which appears
reasonable. The middle of the comment was devoted to explaining
why the code below was potentially incorrect which only served
to add to the confusion.
AFAICT the last volume specifier in a path will cause search to
start from the root of that volume, so any incorrect result can
be avoided by using the new function path_strip_last_volume().
Finally, add a comment at the top of the function that explains
what it does.
Change-Id: If4e4938801f2f81eb52f5d32b5461872995e5e83
Now offers sorting by:
- Album artist, then album name
- Album artist, then album year
- Album year
- Album name
Years are determined by the most recently
released track appearing on an album, if the
value differs between tracks.
On the M3K, instead of by going into Settings,
volume buttons can also be used for quickly
adjusting the current sorting
Change-Id: I2c50059617114fb418336c466fdd37415473ac7d
Some things in core that should probably be plugins steal the plugin buffer
for their own use, TSR plugins have no way to detect or prevent this
lock buffer reserves buffer_size bytes directly after the plugin itself
returns the unreserved bytes still available from the plugin buffer
Change-Id: I5a7849e209129b09400036a594569ef396b1b85f
I think the clipzip has the smallest screen at 96
might need to be enabled for LCD_WIDTH <=128 too
remove scrolling thread info for larger screens
Change-Id: Ic98c9fc0b53f79e90776c13429194f9c37c1d48b
apparently there are tags such as year or genre that are indexed 1 byte
apart, as much as I like the idea of this I cannot come up with a way
to reliably denote 2 16 bit entries from a single 32 bit entry without
losing data or adding bookkeeping which would likely make it pointless
Change-Id: I8a9908575700cab9506c36f5422222145557fa6b
just a little cleanup of ft file filtering code
store result of filter mask to a local var
put skin apply code in its own function
Change-Id: Ib899608f64e36346b9bde07caa5d5ac29de05af9
new operators @^, @$
begins_oneof and ends_oneof
albumartist @^ "L|The L"
Led Zeppelin, The look
albumartist @$ "girls|Boys"
spice girls, beasty boys
Change-Id: I26ce3d8155d970a55e003f74e2f9478db76204f1
the automatic scrolling is not very nice to try and read instead use
OK button to advance and long press std ok to reset to beginning
(or scroll up and down)
Change-Id: I964ccefcd3c16836cc92f52247d7b8e65c6d627b
fix bugs introduced in the switch over to using string_option
instead of if else strcmp trees,
embedded album art should work again
skin parser had an error for 'noborder' and 'nobar'
Change-Id: I957d81e5fa8467b33bbd93d63c4428c36100acca
with root redirect and even relative paths eventually we need the dircache
to get files from the disk
Change-Id: Ia443f473f09dd534674d5fdb71251214ce01eed7
