[EMAIL PROTECTED] wrote: > Hi Tom, > > >>>Tom Schindl <[EMAIL PROTECTED]> 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. > > >>[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
signature.asc
Description: OpenPGP digital signature
