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