small images (never more than 35kB) in a LAN. :)
On May 6, 2011, at 1:12 PM, Martin Gainty wrote: > > depends on available bandwidth as well as the memory available on the client > side > if bandwidth is an issue you may want to implement some manner of compression > with jai (Java Advanced Imaging) > > http://download.oracle.com/docs/cd/E17802_01/products/products/java-media/jai/forDevelopers/jai-apidocs/com/sun/media/jai/codec/TIFFEncodeParam.html > > if your app is rendering small pics where clarity is not a requirement you > probably will never have an issue > if your app is rendering large maps then you'll need to look at JAI or > implement compression algorithm with another tool. > Martin > ______________________________________________ > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger > sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung > oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich > dem Austausch von Informationen und entfaltet keine rechtliche > Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen > wir keine Haftung fuer den Inhalt uebernehmen. > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > destinataire prévu, nous te demandons avec bonté que pour satisfaire informez > l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci > est interdite. Ce message sert à l'information seulement et n'aura pas > n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > > > >> Subject: Re: storing images >> To: users@tomcat.apache.org >> From: alz...@gmail.com >> Date: Fri, 6 May 2011 14:52:50 +0000 >> >> I understand, but i have top 12 images of 35kbytes, no more. >> >> Encoding load is an issue yes, but the images are reflecting callcenters >> call queues and some stuff related so the need to refresh and rebuild the >> images is a requirement. What im thinking is to avoid the generation upon >> servlet calls (servlet only reads and presents the image to callers) and >> start a different thread with a listener in charge to periodically rebuild >> images. >> >> Do you believe regarding memory it can cause a big issue? In worst case it's >> 450kbytes when all images are created and stored. >> >> >> Enviado desde blackberry >> >> -----Original Message----- >> From: Christopher Schultz <ch...@christopherschultz.net> >> Date: Fri, 06 May 2011 09:48:45 >> To: Tomcat Users List<users@tomcat.apache.org> >> Reply-To: "Tomcat Users List" <users@tomcat.apache.org> >> Subject: Re: storing images >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Alexis, >> >> On 5/5/2011 8:19 PM, alexis wrote: >>> Im storing the images as servletcontext attribute. >> >> Uh... in memory? That's a bad idea IMO for two reasons: >> >> 1. Large memory requirements >> >> 2. Likely repeated encoding into a file format like JPEG, PNG, etc. >> >> If you store the files on the disk, you can stream them as often as >> you'd like. If you get a request for an image that already exists, you >> can serve it up, otherwise, you can create it. >> >> You can even create a hash of lock objects or something so that you can >> "lock" the file as it's being written so that the file is only written >> once even if multiple clients are requesting it. >> >> - -chris >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk3D/D0ACgkQ9CaO5/Lv0PAYQQCcCy9k9SxH3YSHxekqSzJQKwPz >> nPAAn3XrYoxXE3E3+FXZ1XfBu3/v9pmW >> =rQaQ >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
