xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: Speed of rasterizer within servlet/web service
Date Thu, 24 May 2001 06:29:23 GMT

----- Original Message -----
From: "Jeff Kowalczyk" <jtk@adelphia.net>
To: "'Batik Users'" <batik-users@xml.apache.org>
Sent: Tuesday, May 22, 2001 5:46 PM
Subject: RE: Speed of rasterizer within servlet/web service

> Thanks for the input, everyone.
> I can simplify my goals down to a representative example:
> - Business chart/graph, map, schematic, diagram, 300px square on avg
> - Most on the order of \batik-1.0\samples\barChart.svg complexity
> - Completely dynamic, SVG is unique for each request, no caching
> opportunity
> - Low-traffic sites, not expecting more than 1 SVG-doc hit per second.
> - Low response latency is important, to keep up with responsive web apps
> - SVG generated on a different server, passed as a SOAP payload from any
> number of web apps I might be working on, intraserver link would be on
> private 100Mbit LAN.
> - Could justify dedicating 1.3GHz Athlon 512Mb DDR running Linux or
> Win2K as a batik rendering server if it would provide low-latency
> renderings for a 1 hit/sec load.

I have no idea if that is going to work or not. Even the overhead of making
sense of a soap payload is going to be trouble if things are tight.
(suggestion: do a pure post to a known servlet instead, avoiding soap
envelope and extra base-64 encoding)

I've just seen that java1.4 beta is out; this adds the new IO subsystem for
really decent file/io performance, and java2d improvements -it could be a
very nice platform for servlets; you'll just need to modify tomcat/catalina
to use the new IO.

> I guess I naively assumed this was the primary intended use of Batik,
> since it is under the apache/XML aegis. Almost every SVG developer need
> to bridge the 'plug-in gap' for the next 12 months or so, until
> mainstream browsers integrate SVG natively. Is it not the case that
> server-side rendering will be a very common use of Batik?

The problem is, SVG is very complex. 500+ pages of complex; it is probably
on a par with display postscript (or even Sun NeWS) for what is possible
regarding rendering and remote code integration. Rendering it client side
makes the most sense. It's what the adobe plug in does and it's what the SVG
applet does.

Trying to do it all server side is not something that makes long term sense,
except for relatively static images, shared charts and the like, or
situations where servers have access to content that users dont have. The
fact that people (myself included) are doing stuff server side right now is
just a transient stage, which we will just have to bear.

> One advantage, I guess, it that the intended app(s) will give the user
> the option to have SVG or batik PNG renderings in their html. Hopefully,
> this will result in a bit of voluuntary user-side load balancing as the
> users get the message about SVG. Adobe's SVG plugin will distribute
> fairly quickly with Acrobat reader 5.

too bad there wont be anything built in to IE6.


To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message