xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Batik and SWT
Date Mon, 03 Apr 2006 12:12:21 GMT
Hi Tom,

> > Tom Schindl <tomAtLinux@gmx.at> wrote on 04/03/2006 04:12:40 AM:

>>> Well that's not really what I had in mind. I really want to replace 
all
>>> AWT components through SWT ones.

> thomas.deweese@kodak.com wrote:
> >    I'm not sure what this means.  Just replace subclasses of
> > java.awt.Component or replace any use of java.awt.*
> > 
> >    If it's the first our main our GUI components live in batik.swing.
> > There are a few things in batik.util, and batik.apps.svgbrowser.
> > 
> >    If it's the second then you will need to replace most of
> > batik.bridge, batik.gvt, batik.ext.awt, batik.swing.  This would be
> > the majority of Batik.

Tom Schindl <tomAtLinux@gmx.at> wrote on 04/03/2006 07:13:23 AM:

> Well I thought of the second one which as you describe it will be a
> nightmare. I had the feeling from the docs that things aren't so
> dependend on each other and gvt is completely seperated from awt/swing.

   GVT is separate from AWT/Swing Components but it uses the java.awt.geom
classes to hold geometry and uses java.awt.Graphics2D interface to 
communicate what needs to be drawn, and uses java.awt.image to support 
filters 
and raster images.  Why wouldn't it... Every JVM is _required_ to provide 
these classes/interfaces since Java 1.2 (circa 1998).

> Please note that I haven't taken a look into batik-code but from my
> naive point-of-view I thought about batik like this:
> 
> SVG => GVT => AWT/Swing
> 
> Where I thought GVT is a vendor neutral representation of SVG e.g.
> something like:

   I take issue with the notion that using java.awt is not vendor neutral. 
 
It might not be what _you_ want but it has been part of Java from the 
start.  If anything is not vendor neutral it's SWT.

> SVG                           ||         GVT       ||    AWT
> ------------------------------||-------------------||-------------------
> <rect                         ||batik.gvt.Rectangle|| java.awt.Rectangle

   Why would we create a batik.gvt.Rectangle when 
java.awt.geom.Rectangle2D
does what we want, and is guaranteed to be on every Java Virtual machine?
Wouldn't that just introduce code bloat, memory bloat, add yet another 
interface for people to learn and really accomplish nothing.

   Further, why do you care if the Rectangle class we use comes from 
batik.gvt or from java.awt.geom?  In either case you need to make it 
displayed...

   In the end the real question is how are you going to render a complex 
bezier path? How are you going to perform convolutions on raster data? 
How are you going to fill complex regions with complex gradients?  What 
about hit testing for pointer events? While we implemented chuncks of 
this it is all built on the Java2D API's - all of which has nothing to do, 

directly, with screen display.

   In fact within our application all rendering occurs to off-screen
bitmaps which is then shown on the screen.  All of that is totally
independent of the AWT 'display' handling and can happily be run in 
headless mode.

   So I don't know anything about SWT but I'm truly surprised that you
feel you need to jettison all of java.awt.


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


Mime
View raw message