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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
