<div dir="ltr"><div>It doesn't add any significant delay. An individual picture is only decoded when a ".raw" file is opened, and the virtual filesystem pretty much simply wraps the results of the Infocom decompression code in a stream so that all file reads read from that memory buffer. As for animations, that'll be an interesting question. The Glk code only deals with drawing static pictures by frame number. So it's likely the existing Magnetic engine does it's own manual handling of animations currently. If so, I could probably add code to present the animations as if they were a graphics format that supports frames, like APNG or GIF, then have the core Glk handle drawing the animation when an animated picture number is specified for drawing. Maybe.. I'll have to see how it goes.</div><div><br></div><div>Paul.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 5, 2019 at 5:06 PM Thomas Dettbarn <<a href="mailto:dettus@dettus.net">dettus@dettus.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

    
<div><p>Sounds like a compromise. How fast is it? Would it be able to handle animations? </p></div></blockquote><div> </div></div></div>