Re: Batik and SWT
Well that's not really what I had in mind. I really want to replace all AWT components through SWT ones. Tom Philip Feldman wrote: It works, but it's slow. Everything is drawn to an offscreen awt component and then blitted to the SWT panel. This covers it in pretty good depth: http://www-128.ibm.com/developerworks/java/library/j-2dswt/ There is also a package from these guys, but their documentation is thin. http://www.holongate.org/ Hope this helps. -Original Message- From: Tom Schindl [mailto:[EMAIL PROTECTED] Sent: Friday, March 31, 2006 1:59 PM To: batik-users@xmlgraphics.apache.org Subject: Batik and SWT Hi, I'm in the process of evaluation Batik for a project we may build in the next months using RCP(=Eclipse). I know I could embedd Swing into SWT but out of curiosity what would be needed to let SWT do the complete Redering of internal SVG presentation used by batik could you point me to the classes used to represent all those things in AWT/Swing. For the first I only need primitives like: - Rectangles, Circles - Texts Thanks for you input. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: Batik and SWT
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. 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. Philip Feldman wrote: It works, but it's slow. Everything is drawn to an offscreen awt component and then blitted to the SWT panel. This covers it in pretty good depth: http://www-128.ibm.com/developerworks/java/library/j-2dswt/ There is also a package from these guys, but their documentation is thin. http://www.holongate.org/ Hope this helps. -Original Message- From: Tom Schindl [mailto:[EMAIL PROTECTED] Sent: Friday, March 31, 2006 1:59 PM To: batik-users@xmlgraphics.apache.org Subject: Batik and SWT Hi, I'm in the process of evaluation Batik for a project we may build in the next months using RCP(=Eclipse). I know I could embedd Swing into SWT but out of curiosity what would be needed to let SWT do the complete Redering of internal SVG presentation used by batik could you point me to the classes used to represent all those things in AWT/Swing. For the first I only need primitives like: - Rectangles, Circles - Texts Thanks for you input. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [attachment signature.asc deleted by Thomas E. DeWeese/449433/EKC] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Batik and SWT
[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. 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. 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. 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: SVG || GVT ||AWT --||---||--- rect ||batik.gvt.Rectangle|| java.awt.Rectangle x=192.0|| || y=105.0|| || width=247.0|| || height=153.0 || || fill=#ff || || fill-opacity=1.0 || || stroke=#00 || || stroke-width=1.0 || || stroke-opacity=1.0 || || stroke-linecap=round/ || || Tom signature.asc Description: OpenPGP digital signature
Re: Batik and SWT
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). 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Batik and SWT
[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
RE: Batik and SWT
It works, but it's slow. Everything is drawn to an offscreen awt component and then blitted to the SWT panel. This covers it in pretty good depth: http://www-128.ibm.com/developerworks/java/library/j-2dswt/ There is also a package from these guys, but their documentation is thin. http://www.holongate.org/ Hope this helps. -Original Message- From: Tom Schindl [mailto:[EMAIL PROTECTED] Sent: Friday, March 31, 2006 1:59 PM To: batik-users@xmlgraphics.apache.org Subject: Batik and SWT Hi, I'm in the process of evaluation Batik for a project we may build in the next months using RCP(=Eclipse). I know I could embedd Swing into SWT but out of curiosity what would be needed to let SWT do the complete Redering of internal SVG presentation used by batik could you point me to the classes used to represent all those things in AWT/Swing. For the first I only need primitives like: - Rectangles, Circles - Texts Thanks for you input. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
