not even I would consider commiting something that outright breaks stuff :)
2009/8/14 pondlife <pondlife_at_ntlworld.com>:
> A small (but probably non-useful) comment:
> I originally envisaged buffering as being a strictly file-based thing - a
> layer on top of file i/o, rather like dircache.
> You'd "bufopen" a list of files you were planning to read and it would
> attempt to pre-read them into memory. You'd then "bufread" the data which
> could come either from the buffer (good!) or from the disk (bad, but
> inevitible sometimes). Then, when you're pretty sure you no longer need a
> file, you'd "bufclose" the buffer handle. Internally, the allocation would
> of course have to make judgements about discarding buffered data as and when
> new space was needed, using the hints given via the file type.
> However, it seems to have become malloc-by-proxy. :)
wrong buffer_alloc(), I'm using the one which steals some audio_buffer
before playback starts... (now if we just had one malloc there wouldnt
be this confusion :D )
2009/8/14 Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>:
> how does it work in it's current state, and how's it supposed to work
> I'm thinking we could just buf alloc the whole wps, which would "just"
> requires restarting playback on changing which wps changing often does
> nowadays anyway (if aa size changed). That would reduce the footprint of
> wpses if they're not too complex/overloaded.
> Best regards.
instead of multiple static arrays in gui_wps there will be a single
big one which is used as needed during parsing
wps_data has a seperate buffer for anything that has more than one of
it (images has a huge one, then there is the MAX_<something> values
which are arbitrary, i.e MAX_PROGRESSBARS is 3, but only one per
viewport, there is a 1K string buffer which is rediculouly huge
considering we moved mostly to graphical screens instead of text (even
then it was huge), but the number of string was limited.)
What I'm in the proccess of doing is cutting down the gui_wps struct
to something that could potentially fit on the stack so screens could
use it to do their drawing (the top of the time/date screen is an
So far what I've moved into this new scheme is the progressbar
handling, images (Except backdrop) and strings. I'm not sure what the
delta will be, but I think once its all done the needed space will be
slightly bigger for a given .wps (some tokens which are currently not
stored need to be stored, and the token struct is slightly larger),
but the total ram useage will be lower or about the same canceling it
all out... (hopefully)
I want to get this in in its current state because the next steps are
changing either the tokens or the viewports (probably viewports)
across which involves changing a fair bit of display logic which I'd
rather do separately.
This works, I've tested on my DAPs, but please test on yours also
Received on 2009-08-14