Hi Troy, Thank you very much for your suggestion. The PNG images that I was loading were large (1200 x 900). Using smaller images (400 x 300), I can easily load 200+ images with no noticeable delay. There is clearly no point to load images that are higher resolution than will be displayed, so I will have to find a happy tradeoff between appearance and performance (as is often the case!).
Is it right to assume that since I am reusing a single loader over and over that the strain on the memory comes from the array that holds the Bitmap objects? All the best, James --- In [email protected], "Troy Gilbert" <[EMAIL PROTECTED]> wrote: > > > I find that the image loading + Bitmap generation takes about 0.1 to > > 0.2 seconds per image for the first ~50 images (this is fine because > > the animation frame rate is set to 0.5 seconds per image, so the > > loader keeps up), but after image 60+ it can take 3-5+ seconds per > > image, which becomes problematic! > > It sounds as if you may be running into memory issues. How large are > your images (dimensions)? After 60+ images you may be getting a delay > as memory starts to swap to/from virtual memory to service the > allocation of the bitmap data. > > One way to work around this would be to ditch older images... of > course, if the user wanted to loop or control the playback, this would > be problematic, but depending on the UI scenario you may be able to > rely on the browser's cache. > > You could also potentially generate a FLV on the server based on the > images the user requests. I know you can use ffmpeg (I think) to > generate FLVs, perhaps you can also use it to generate a FLV based on > an image sequence. You could then just stream the FLV to them, which > would internally (and natively) handle on the memory issues more > efficiently and gracefully). > > Troy. >
