Re[2]: [Gnash-dev] Re: Bitwise stream reading performance

[Udo Giacomozzi]

Hello strk,

Monday, August 27, 2007, 2:15:42 PM, you wrote:
s> gnash::stream exposes a get_underlying_stream, which is currently used
s> by some tag readers (embedded bitmaps usually). If we can remove any
s> use of the underlying file, cache can be enabled at the gnash::stream level,
s> otherwise we're stuck in doing it in the tu_file directly.

Why do they need access to the underlying stream? Odd.


s> Now, doing it in tu_file might be good, in case some tu_file implementation
s> have caches themselves, to avoid duplication, and could also mean we might 
tweak
s> cache size based on input channel.

tu_file works byte-wise while the stream can read bits. The read-ahead
cache would only (or, at least "mostly") benefit for the bitwise
reading process. After all fread() *does* caching, but that doesn't
help us much.

Currently to read just two bits a complicated algorithm must be
processed which in the worst case has to read a single byte and do a
few shifts and a few masks. Instead, if we always have a buffer of at
least 8 bytes we can just treat the head of the buffer as a 16 bit
integer and do one shift and one AND. As said, the endianess of the
hsot machine matters in this case.

The buffer doesn't have to be big (8 bytes is already enough).

I could implement such a cache if someone can point me to
documentation explaining the byte structure of SWF files (first of
all, is it MSB or LSB first?).


s> Finally, we might want to implement bitcache as a separate class,
s> which could be used by an higher level (say, shape reading).

How would shape reading benefit from that? I think it's enough if we
implement it in the stream class.

Udo