On Monday 07 July 2003 12:25, Mark Hood wrote: || > Date: Thu, 3 Jul 2003 18:08:41 +0200 || > From: Bernd Fondermann <[EMAIL PROTECTED]> || > || > Detaching/Reattaching plus changing the scene graph in between not only || > is memory consuming, it is also time consuming. (Btw, freeing memory is || > time consuming, too.) || > Since a servlet is meant to serve multiple pages (jpgs in your case) per || > second in parallel (isn't it?), you surely will run into scalability || > problems here. It's by design. || > I use the same approach by avoiding detaching, by running j3d in a || > separate process and by propagating the rendered image from j3d process || > to the servlet engine process. || || Interesting... do you use a single JVM instance to run all J3D requests || separate from the servlet engine, or multiple JVM instances for a set of || requests? What kind of performance do you get?
one JVM for J3D, another one for the servlet engine. this basically is a variation of the classical 3-tier architecture for web applications (the most common instance would be: web browser/web server/relational database). performance... well, you don't get anything comparable to your locally installed first-person-shooter :-). but the bootleneck is not interprocess communication between servlet engine and J3D. instead, what's reducing client-side fps is the network transfer of the image(s) to the client (HTTP protocol and internet bandwidth). next step would be to look into streaming technologies. why I chose this specific setup? very-thin-client! only a simple webbrowser is needed on the client, no java, no vrml plugin, no long data/application-prefetching downloads, no need to synchronize clients over the net. startup time is: nearly immediate. let's put it this way: performance is as good as it needs to be for the user to get the impression he is really talking to a webserver. and if you know how some web apps suffer from bad designed SQL queries, I'm quite happy with it. Bernd =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
