[swfmill] Anyone using swfmill?

[daniel fischer]

Anders,

thanks very much for your reply (to the others too, i will likely also get back to you...)

"Anders N. Schultz" <as at ipos.dk> (on Mon, 11 Jul 2005 22:00:38 +0200):

  > Recently, we encountered a problem when having to show hundreds of
  > full-screen sized images (for a real esate client) loaded dynamically into
  > Flash.

  > It seems that swfmill has a problem when it is asked to make an .swf
  > file based on an xml file having a large quantity of big images. I used the
  > same format for my xml file as described on the swfmill pages on the net.

this triggered my interest. yes, swfmill is not memory-optimal in any sense. i have a rough idea how to do the whole thing with an event-based ("streaming") model, but that is quite an effort... using a "object model" approach (keeping a model of the whole SWF in memory) in favor of a (more efficient but more involved) "stream" one was a decision during early (<0.1-ish) swfmill development, based on the idea that "the flash player will load this into memory too". of course the flash player handles SWF in a kind of streamed way, but still-- i just did some testing and it seems to support the assumption:

i took a bunch of images (3453 jpegs in 640x480, making up roughly 233MB on my filesystem) and constructed a swfmill-s file like the slideshow example i recently posted (with an adaption of steve's library.py, btw).

running this thru swfmill took about 5 minutes on my <2GHz P4, memory consumption went up to approx. 1.2GB, but the resulting SWF summed up to an expectable 228MB. consider: swfmill uses its internal stylesheet to build an XML DOM Tree representing an SWF containing all those images, with the image data included as base64 text (about tripling the size to ~700MB), then transforms this to an internal representation (adding 230) and -i didnt check but i think- even writing to another buffer before actually flushing it thru gzip onto your filesystem (giving around 1.2GB).

but to the point: playing this beast of an SWF in mozilla looks kind of ok (the images were in wrong order due to my incomplete python but elsewise seemed fine), but quickly results in even worse memory consumption from mozilla. i stopped it at about 1.6Gig so as not to make my machine unusable :/

so my thesis here is that producing such a file _should_ work with swfmill, given you have enough RAM or swap space. of course things get awfully slower if your machine has to swap, and i wouldn't recommend running this on a server which has anything else to do. and if you run out of swap space, strange things will happen indeed (i can't guarantee swfmill will fail gracefully there). BUT: it's not a good idea anyway, as no sane user would run this. or can you teach me otherwise? how could such a huge library be actually useful? why not create a single SWF for each image?


  > An odd thing was that swf files generated would vary in file size - even
  > though no changes was made in the xml file. Sometimes the size would be a
  > couple of megabytes, sometimes less and sometimes more. Very puzzling for me
  > since the .xml file stayed the same.

as said, if you run out of swap space, anything can happen. but indeed, swfmill should complain or at least crash if that happens... it didnt?


  > the alarming thing was that when I then decreased the
  > number of images I could not get a successfull .swf file anymore. I ended up
  > with the same two images in the xml file as at the outset but was not able
  > to get a proper .swf file anymore.

are you saying that one independent run of swfmill affected its behavious on the next? my natural reaction is to shout "impossible!", but it seems i'm doing computers too long to really do so, and also i heard something similar recently-- was it on the list? i cant recall.

a reproducible testcase would make my work much easier here ;)


  > I ended up thinking, however, that swfmill has some
  > sort of stability issues ...

oh, it sure does. it's all just a giant hack! but seriously: that's one of the reason for calling it 0.X alpha. i have some ideas of how to get to beta or -whohoo- "stable", but i have to put these down sometime else, they're still too rough.


  > I don't know what you can make out of my experience .. 

tales from the limits are very valuable feedback, thank you.

-dan

-- 
http://0xDF.com/
http://iterative.org/