Hey Ian! Even though I´ve had kind of a hard time changing the architecture yesterday, I managed to make (process) the images once and keep them on the disk and the performance increase is awesome! The only bad thing is that the execution time of the script is big as it has to process more than 100images, but I can live with that, my users can´t live with the 5+ seconds it took to load the pics ;) You idea is very interesting though, I will keep this email for future reference :)
Thanks a lot! Marcelo. On 5/18/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
Hi Marcelo, As you wish; however creating them programmatically as required and then storing them on disk in a cache (as I suggested above) does mean a minimum of work when you want to upload a new image; the first user to look at your new image (who may well be you!) will have a slight delay, but after that it'll be nice and fast. I'd have thought that was less work - given your current architecture - than reprocessing a bunch of images manually. Ian On 5/17/06, Marcelo de Moraes Serpa <[EMAIL PROTECTED]> wrote: > Hi Ian! Thanks for the reply ;) > > IThat could solve the problem with my current architecture, but I guess I > will just store many different versions of the image **on the disk** instead > of using gd each time the users requests the image. > > See the topic at as.org: > http://www.actionscript.org/forums/showthread.php3?t=106049 > > Thanks again! > > Marcelo. > > On 5/17/06, Ian Thomas <[EMAIL PROTECTED]> wrote: > > > > Hi Marcelo, > > The obvious optimisation would be to cache the scaled images on the > > server - save them under a name dependent on the dimensions of the > > generated image. > > E.g. > > trees.jpg > > becomes > > cache/trees_400x300.jpg > > > > Then when you serve the image, just check to see if the file is in the > > cache - if it is, serve that, if not then regenerate before serving > > it. > > > > I've done that on image galleries a lot and it works fine. > > > > In terms of stopping the user redownloading the image - if the image > > is served as a 'standard' static image, the client's local cache > > should take care of it without you having to do any work. > > > > In short - all those optimisations should be possible serverside > > without you having to do anything at all to your Flash code. > > > > HTH, > > Ian > > > > On 5/17/06, Marcelo de Moraes Serpa <[EMAIL PROTECTED]> wrote: > > > Hi! > > > > > > I´m doing a research on RIA´s optimization techniques and I plan to > > > implement such in my app´s next version as its getting bigger and bigger > > so > > > it became a necessity to optimize it. > > > > > > Currently, I´m using shared fonts, shared symbols and shared classes > > (the so > > > called "dll" swf) that are all loaded once in the application lifetime, > > > avoiding the download redundancy and optimizing the size of the > > subsequent > > > swfs. However, my application is still not fast as I would like it to > > be, > > > the main reason is obvious, it uses too many classes (and v2 framework > > adds > > > a great deal to the class inventory). The second reason is becouse of > > the > > > nature of my app: Its an online picture album. The images are stored in > > 1MP > > > at the server and each time the client requests the image, its converted > > > (scaled down) at runtime using GD. It´s very flexible as I can make many > > > different size images without worring about saving them, however, and I > > > would like the oppinion of more experienced web developers, I think it > > would > > > bring me problems when my site gets a very high trafic AND it is slower > > than > > > if I would just load the image without pre-processing it. > > > > > > Also, I´ve not implemented controls such as to prevent the client to > > > redownload the picture if it is already downloaded - how could I do > > that? > > > Something that came into my mind is to use SharedObjects to cache data > > and > > > some logic to implement such thing. > > > > > > Any suggestions would be very much appreaciated! > > > > > > Thanks, > > > > > > - Marcelo. > > > _______________________________________________ > > > [email protected] > > > To change your subscription options or search the archive: > > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > Brought to you by Fig Leaf Software > > > Premier Authorized Adobe Consulting and Training > > > http://www.figleaf.com > > > http://training.figleaf.com > > > > > _______________________________________________ > > [email protected] > > To change your subscription options or search the archive: > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > Brought to you by Fig Leaf Software > > Premier Authorized Adobe Consulting and Training > > http://www.figleaf.com > > http://training.figleaf.com > > > _______________________________________________ > [email protected] > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
_______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
