[Scummvm-devel] File handling revamp

[Max Horn]

Am 29.07.2008 um 11:54 schrieb Lars Persson:

> Hi!
> This sounds execellt!
> What I discovered when looking at the file performance issues for  
> Symbian is that due to alignment stuff, even an 16 bit read from an  
> engine boils down to two byte reads.
>
> So having a generic cache function would really be benefitial, since  
> that is what I'm doing in the Symbian file backend right now, and  
> that has only taken a couple of days to implement.
>
> Of course this will depend on what you want to achieve with the  
> generic buffering, but I think thats better than relying on  
> underlaying system calls which might or not be available.

What I want to achieve is to make life easier for porters, and engine  
authors. Engine authors should not have to worry about whether they  
read byte-wise or not (they already don't, but I want it to stay like  
that).

And porters should at least be made aware of the fact that this will  
happen. If multiple ports need to implement a buffering system, then  
it sounds like a good idea to write a lean and generic buffering class  
once, so that it can be shared. Hence, what it will do and not do,  
depends mostly on what porters ask for. Oh, and ideally, porters would  
also contribute to it, since they know best what it should be doing :).

One approach would be to provide a BufferedReadStream class (and also  
a BufferedSeekableReadStream class) which could then wrap around any  
(Seekable)ReadStream, and maintain a read buffer of arbitrary size (of  
course seeking would have to be taken into account etc., but that  
shouldn't be too difficult). Then porters could simply create their  
own unbuffered FileReadStream classes (e.g. SymbianFileReadStream).  
When asked for a file stream, you create a SymbianFileReadStream, then  
a BufferedSeekableReadStream wrapping your custom class.

The advantage of that: Buffering code has to be written and maintained  
only once, yet it would still be 100% optional; if your port already  
has great buffering logic, or your OS already provides good enough  
buffering, you wouldn't have to use BufferedSeekableReadStream.


Now, that's just a quick idea I had, I didn't spend too much thinking  
about it. If people see a better way or see flaws in this approach  
(besides the slight overhead incurred by it, but I would hope that it  
is not worse than we have already), please state so!


Cheers,
Max