From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Fri, 16 Jul 2010 11:08:28 +1000

On 16 July 2010 10:46, Jonathan Gordon <jdgordy_at_gmail.com> wrote:
> On 16 July 2010 10:28, Edgar Toernig <froese_at_gmx.de> wrote:
>> Jonathan Gordon wrote:
>>>
>>> > -#define SKIN_BUFFER_SIZE (MAIN_BUFFER + REMOTE_BUFFER + SKIN_FONT_SIZE) + \
>>> > +#define SKIN_BUFFER_SIZE (MAIN_BUFFER + REMOTE_BUFFER + 5*SKIN_FONT_SIZE) + \
>>> >                          (WPS_MAX_TOKENS * sizeof(struct wps_token))
>>
>>> The eventual goal is to make that buffer resizeable, but untill then
>>> doing that change is a waste for most people. (On the clip the font
>>> size is 3K IIRC but on targets with I tihnk more than 8MB ram it is
>>> 10K and the extra space isnt usually needed anyway.
>>
>> Hmm... we are talking about ~0.1% of memory (from 12k to 24k).  I think,
>> most people will give up 1s of sound pre-buffering for fancier graphics.
>> There must have been a demand else support for multiple fonts wouldn't
>> have been added in the first place.
>>
>> But what's the point for multiple fonts when there's not enough buffer
>> space for them?  To me it looks like the buffer size calculation was simply
>> not adjusted when multiple font support was added.  Now you have the effect
>> that a WPS sometimes loads and sometimes not, depending on SBS and selected
>> user font.
>>
>> Why not increase it until the resizable (or configurable) buffer size is
>> implemented?  This would at least fix a problem ...
>>
>> Ciao, ET.
>>
>
> You are preaching to the choir here, The way people care about tiny
> amounts of RAM is rediculous, but that is what we do... does
> increasing it to 2 *SKIN_FONT_SIZE work?
>
> The problem with the mono targets is that there is no backdrop buffer
> and a much smaller image buffer, the backdrop one is the important
> one, on the bigger targets when the backdrop is shared between all
> skins you have a couple hundred KB free for fonts and stuff. On mono
> there isnt this huge buffer and really the size hasn't been calibrated
> (for want of a better word).
>
> So, if 2 or 3 works I'd be interested in a atch which increases
> MAIN_BUFFER for mono targets as a stopgap solution.
>

I've just commited a patch to stop the segfault
Received on 2010-07-16