|
Rockbox mail archiveSubject: Re: WPS ram overhaul take 2...Re: WPS ram overhaul take 2...
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Fri, 14 Aug 2009 08:27:14 -0700 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. :) > > pondlife > 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 > finally? > > 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. > <short version> instead of multiple static arrays in gui_wps there will be a single big one which is used as needed during parsing <long version> 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 obvious candidate). 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 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |