Re: Batik and SWT

[Steven Shaw]

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
[EMAIL PROTECTED]

Tom Schindl <[EMAIL PROTECTED]> 04/03/2006 08:25 AM Please respond to batik-users

To batik-users@xmlgraphics.apache.org cc Subject 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: Binary data

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]