Rockbox Technical Forums

Support and General Use => Theming and Appearance Customization => Topic started by: oori002 on February 03, 2007, 03:54:21 AM

Title: Buffer size too small (H10)
Post by: oori002 on February 03, 2007, 03:54:21 AM
Hi rockboxers :)

I just wanted to test my new WPS (including album art). the album art works just fine but the when I try to load more images the simulator write that the given buffer is too small =\

the size of all the images that sould be loaded into the buffer for the WPS is about 168 KB (its not that much).

is there something I can do to fix this problem? (already tried to swich the images to 16 bit but its not shows properly)

P.S
I searched in the forum and didnt found anything about that problam.

Thx
Ori
Title: Re: Buffer size too small (H10)
Post by: XavierGr on February 03, 2007, 01:21:31 PM
You must change the buffer size (iirc) responsible for the WPS in the source code.
Then you can compile and run the build on your unit.

I don't remember though where exactly is the buffer size define...
(maybe apps/gui/gwps.c , apps/gui/gwps.h)
Title: Re: Buffer size too small (H10)
Post by: Genre9mp3 on February 03, 2007, 01:38:12 PM
apps/gui/gwps.h

line 68-69

Code: [Select]
#define IMG_BUFSIZE ((LCD_HEIGHT*LCD_WIDTH*LCD_DEPTH/8) \
                   + (2*LCD_HEIGHT*LCD_WIDTH/8))
Title: Re: Buffer size too small (H10)
Post by: oori002 on February 03, 2007, 05:39:41 PM
umm.. I cant do that :(

I gess that i have to just leave the theme on the side :(

Thx anyway

B.T.W

Why not changing the source code so the buffer will be bigger on every normal build? This can disrupt something?
Title: Re: Buffer size too small (H10)
Post by: soap on February 03, 2007, 05:47:41 PM
Increasing the WPS buffer decreases the audio playback buffer, leading to more frequent hard drive spins, and thus decreased battery life.
Title: Re: Buffer size too small (H10)
Post by: oori002 on February 04, 2007, 01:42:01 AM
I dont think that increasing the buffer in 100 - 150 KB will metter something but if you say so you must be right
Title: Re: Buffer size too small (H10)
Post by: Llorean on February 04, 2007, 03:48:09 AM
It may not matter to you, but stealing 150kb from all users, just so one theme that they don't use could have a dancing puff, is a bit much.
Title: Re: Buffer size too small (H10)
Post by: oori002 on February 04, 2007, 08:19:56 PM
haha.. lol

got it.. thx
Title: Re: Buffer size too small (H10)
Post by: rah on February 25, 2007, 12:37:56 AM

I dont think that increasing the buffer in 100 - 150 KB will metter something but if you say so you must be right


Hi,

There seem to be three buffers:

main_backdrop - defined in /apps/recorder/backdrop.c (line 26)
wps_backdrop  - defined in /apps/recorder/backdrop.c (line 27)

and the main wps graphics buffer whose size is defined by the
#define IMG_BUFSIZE   - in apps/gui/gwps.h (line 68)

Most themes that I've seen try to get everything into the main wps
graphics buffer. This usually gets pretty full just by loading the
main background (which often consists of mostly magenta).

A way around the memory problem would be to put stuff you are sure
won't get overwritten by text or the progress bar, into a wps
backdrop graphic.  You load that with %X (upper case) in your wps
file.

The user 'soap' said that giving more memory to the main wps
buffer would steal it from the main playback buffer.  Isn't that
dynamically allocated, and, in any case, is many MBs, and varies
considerably between players?  Another few KBs might not make a
big difference on players that have a decent amount of memory.  
If memory is short, it maybe an idea to lose the wps_backdrop
functionality completely, and just give it to the main wps
graphics buffer.  Once you've loaded your main background, you've
got precious little memory left to add your dynamic graphics (on
the Iriver H300, 9680 bytes).  So, since there are so many
conditional directives in the code, anyway, wouldn't it be
reasonable to give more memory to the wps buffer on a model by
model basis?

I've been trying to tidy up some of the posted themes for the
H300, and many of the themes fail to load all of the dynamic
graphics. After the main bg is loaded, the remaining 9680 bytes or
so gets eaten really quickly. On the Iriver, the main buffer is
220*176*16/8 bytes.  I think giving half as much again ~ 38K would
satisfy all but the most lavish theme designer, and even 10K would
allow most themes to load.

If you make this trivial change (below) to apps/recorder/bmp.c,
and recompile your sim, you'll see just how little memory theme
designers have to play with.

Sorry for the long post.

Cheers,

===Rich

--- bmp.c.org   2007-02-24 20:42:31.000000000 +0000
+++ bmp.c       2007-02-25 04:54:05.000000000 +0000
@@ -275,7 +275,7 @@
     /* Check if this fits the buffer */
     if (totalsize > maxsize) {
         DEBUGF("read_bmp_file: Bitmap too large for buffer: "
-               "%d bytes.\n", totalsize);
+               "%d bytes,  max = %d.\n", totalsize, maxsize);
         close(fd);
         return -6;
     }
@@ -546,6 +546,6 @@
 
     close(fd);
 
-    DEBUGF("totalsize: %d\n", totalsize);
+    DEBUGF("totalsize: %d,  maxsize: %d\n", totalsize, maxsize);
     return totalsize; /* return the used buffer size. */
 }

Title: Re: Buffer size too small (H10)
Post by: Llorean on February 25, 2007, 07:12:49 AM
A user could also get around that by using several partial images rather than one fullscreen image, so that instead of wasting space with magenta bits, there's nothing actually in that space.

It's really not suggested that you use anything but %X for full screen images. It shouldn't be necessary.

And no, the audio buffer is statically allocated. Anything you reserve for the WPS is permanently reserved for the WPS. A careful balance needs to be maintained between how much memory is preserved for those people who actually care only about battery life (those who say "It's a music player, I don't even LOOK at the screen except if I need to see the title of the track, so my WPS is very simple") and those who want flashy graphics.

While it's only a marginal difference expanding the buffer, you are costing another group a very small amount of battery life in doing so. And I've seen a lot of WPSes that seem to do just fine with the limited memory they're given. The WPS wasn't really meant for animation.