You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Philip Feldman <pf...@proteus-technologies.com> on 2006/04/01 00:40:07 UTC
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:tomatlinux@gmx.at]
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: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Batik and SWT
Posted by Steven Shaw <st...@ca.ibm.com>.
I have done something similar in the Eclipse GMF project which supports
rendering of SVG images on an SWT canvas.
In essence, we are rendering through a Graphics2D adapter class which
delegates to the individual graphics calls to a SWT Graphics class. If
there's isn't a direct mapping, or support doesn't exist in SWT for a
particular graphics call, then I throw an exception and do a straight AWT
rendering to a BufferedImage which is subsequently converted into an SWT
Image.
You could take a look at our implementation in open source:
www.eclipse.org/gmf
org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.graphics
.Graphics2DToGraphicsAdaptor
and
org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.svg.
SWTImageTranscoder
Regards,
Steve.
________________________________________
Steven R. Shaw
Rational Modeling Platform Diagram Layer Lead
Rational Software | IBM Software Group
770 Palladium Drive, Kanata, ON, Canada, K2V 1C8
tel: 613.591.7979
steveshaw@ca.ibm.com
Tom Schindl <to...@gmx.at>
04/03/2006 08:25 AM
Please respond to
batik-users
To
batik-users@xmlgraphics.apache.org
cc
Subject
Re: Batik and SWT
thomas.deweese@kodak.com wrote:
> Hi Tom,
>
>
>>>Tom Schindl <to...@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 <to...@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
Re: Batik and SWT
Posted by Tom Schindl <to...@gmx.at>.
thomas.deweese@kodak.com wrote:
> Hi Tom,
>
>
>>>Tom Schindl <to...@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 <to...@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
Re: Batik and SWT
Posted by th...@kodak.com.
Hi Tom,
> > Tom Schindl <to...@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 <to...@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
Re: Batik and SWT
Posted by Tom Schindl <to...@gmx.at>.
thomas.deweese@kodak.com wrote:
> Hi Tom,
>
> Tom Schindl <to...@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.
>
>
> 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="#ff0000" || ||
fill-opacity="1.0" || ||
stroke="#000000" || ||
stroke-width="1.0" || ||
stroke-opacity="1.0" || ||
stroke-linecap="round"/> || ||
Tom
Re: Batik and SWT
Posted by th...@kodak.com.
Hi Tom,
Tom Schindl <to...@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.
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:tomatlinux@gmx.at]
> > 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: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
> >
> >
>
> [attachment "signature.asc" deleted by Thomas E. DeWeese/449433/EKC]
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Batik and SWT
Posted by Tom Schindl <to...@gmx.at>.
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:tomatlinux@gmx.at]
> 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: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>