Hello strk, Monday, August 27, 2007, 11:22:38 PM, you wrote: >> That won't work as the read-ahead cache would load data (= steal data) >> from tu_file which instead should be read by these special tag >> loaders.
s> tag loaders which will use the underlying stream will NOT enable s> the cache.. The problem are tag loaders *before* those tag loaders you talk about. "Stream" will read ahead data for a tag that reads bitwise and may read into a tag that will not use the cache. You said that "stream" knows the length of a tag. Now this could solve that problem but I'm still not very happy with this multi-level access design. As it makes things more complicated I'd go this way only if redesigning into a more straightforward is even more complicated. >> I fear we won't be able to implement any kind of caching mechanism >> unless *everything* uses "stream" to load data or bit-reading is >> implemented in tu_file itself. The latter case is the worst thing I >> can imagine. s> I'd still research on externalizing the cached-bits-reader into a specialized s> class. Again, can you explain what real benefit? The cache implementation itself won't be big, just a handful lines of code. IMHO it's counterproductive to use a special class for this. The stream would become a *wrapper* for the cache class... Udo _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
