The speed issue is more related to page loading - at least that's as far as I've observed - which can be expected because of the size of the jar files in V0.9 (and the fact there's 3 of them!). Once jar files are downloaded, they should remain in the java runtime cache until the user deletes it (or cache runs out of memory). So theoretically speaking, once the java is cached, it should be quick to load... however, if users are likely to be uploading from internet cafes etc, then the jar files would be downloaded each time, and that could be a real pain! I have also noticed that if I have a lot of browsers and tabs open in firefox, V0.9 does tend to respond slower to mouse clicks, but obviously a bloated firefox doesn't help, and I don't think many people have open sessions with 100 tabs or more!
I think as far as actually resizing images goes, I would have thought they used the same algorithms (in fact they are fairly generic - e.g. a bicubic algorithm is a bicubic algorithm, it doesn't have alternative methods to achieve the same results - See here if you're interested). Actually this brings me to the next point - resize image quality - ask yourself it it matters if these images come about a bit "blocky" or jagged, or do you want them to still look high quality... As mentioned in my notes, I've set the default compression to Bicubic, which is the best quality resizing algorithm, but as a consequence is slightly slower (not sure by how much, obviously depends on the CPU of the client / user). To get the resizing to work faster you can set the algorithm to none, but this leaves the blocky/pixelated edges. I guess the real way is to try uploading 20 images and time it for both methods (or time it as far as resizing goes - actually timing uploads to your server for comparing is unreliable, due to fluctuations in server load, unless you don't mind doing it a large number of times to improve the statistics!).
Thus it all ultimately depends on end user. It sounds to me like V0.9 would be best for you if you want a good quality/professional appearance (and it can be skinned, although I've not looked into that), but as said... if using internet cafes or slow PCs... and the other thing I mentioned before - V0.88 has the ability to convert bmp to jpg on the fly - V0.9 doesn't seem to work - there are some occasions where that can be useful. Well perhaps you could offer both versions so the user can choose which to use depending on their circumstances. All you need to do is rename the files for one of them to something else, like jpload2.php, album_jupload2_body.tpl, and the link to the template needs to be updated in jpload2.php - you look for the line:
and replace with The action file should work regardless of which java page was loaded, so no need to rename them. Obviously you would need to add buttons/links for both versions, with maybe some explanation by them. If I remember, the template files to modify the buttons in are album_cat_body.tpl and album_personal_body.tpl. You can modify these just like a html file (but as you will see they also include some code / variables created in the php pages) - anyway its not hard to control layout in the templates if you know some html. Of course you may already know how to do it, so I'll shut up now
