We have to make a decision that will impact SWFUpload v2.5.0 and I don't think we can do it without your input.
We have implemented client side image resizing in v2.5.0. If you've been testing you've noticed that if your resized image is very large (even 600 x 600 pixels) it takes several seconds to process the data.
This is because ActionScript is really really slow when it comes to the "heavy lifting" of re-encoding the data in JPEG or PNG format. Reading, resizing and uploading the data is all quick and compared to encoding is irrelevant.
However, we've found an encoding library written in C and integrated into Flash using Alchemy that is super fast.
Unfortunately this super fast C code causes swfupload.swf to go from a file size of 24 KB to 183 KB. It appears that the library is simply attached to our SWF without any kind of compression. (If anyone knows any compiler switches or anything to reduce the file size please let us know).
So what is more important to you? Faster encoding (milliseconds vs seconds) or file size?
February 17, 2010 - 3:32pm
Client image-resizing is a feature that I never intend to use. It is imaginable to make it optionnal? One lightweight swf for the main purpose of the application, another for «extra features».
February 17, 2010 - 4:11pm
We have already had to split SWFupload to support image resizing. You want to use swfupload_fp9.swf for your code.
That code will stay the same size as it is now and does not include any image resizing stuff. It is designed for compatibility with Flash Player 9 with full Flash Player 10 support (e.g., security button support).
February 18, 2010 - 12:45pm
Once a person downloads the swf file, it should be cached in their browser for each additional page view to the upload pages, and 183kb isn't all that much anymore for people on broadband.
However, if somebody is uploading say 20 images, and it takes a few minutes extra because the resizer is slow, then I think people will complain more about that then the extra 2-3 seconds they had to initially wait.
And as you commented before, if somebody doesn't need to resize images, they can just use the fp9 version.
I plan to have 2 different file upload pages - one for general file uploading (doc, xls, ppt, etc), and one for web files (mainly images). So what I intend to do is have fp9 on the file upload page, and the resizer working on the image upload page.
February 18, 2010 - 4:48pm
Most will download the swf file once... and potentially resize and upload many times.
March 14, 2010 - 11:46am
With two versions (swfupload_fp9.swf +swfupload.swf) and let user (programmer) to decide. As for today, I'm not using the resize, and the size of the all project is VERY important for me. At the other hand, if you are doing resizing, no doubt performance is an issue.
I think the best will be to have the #c code as external component (plug-in?) with late/ lazy bind. So I can configure to load this model latter.
My two cents.
April 3, 2010 - 3:08am
don't need client resizing, i do it on the backend with image magick + a some other modifications like captioning, adding drop shadows etc., so resizing is just but tiny fraction of any backend image modifications that my app does.
April 14, 2010 - 5:39am
Thanks for your great work.
I think if one needs the resize functionality then the speed of encoding is very important. I am using resize and have noticed the speed increase with beta 3.
April 14, 2010 - 2:06pm
I definitely need the smaller file size. Some people in this country still use 56k dialup. So when they want to post, the image uploader doen't appear on the page until after a loooong time. It seems to them to be broken.
I would definitely prefer the resize to take longer than the appearance of the download control to take long. 24KB to 183KB is a huge difference, and 183KB for an element on the page is huge.
Can I perhaps get the 24KB file to use? Please I need it urgently.
April 21, 2010 - 3:12am
A (one-time) wait until 200kB swf uploader ready will paid back with faster server response time, _from user's point of view_, he don't know about resize on his side.