xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Schindl <tomAtLi...@gmx.at>
Subject Re: Batik and SWT
Date Mon, 03 Apr 2006 12:25:48 GMT
thomas.deweese@kodak.com wrote:
> 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).
> 
> 

There was my misunterstanding I thought there some rendering geting
started at this level but as you outlined this is not happening.

>>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.
> 

Right.

>    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...

Accepted.

> 
>    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.
> 

Yes. What I really need is a transformation layer between AWT-Classes
and SWT.

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

That's not what I wanted but haven't been sure when rendering starts.


Thanks for detailed reponse

Tom

Mime
View raw message