hello,
I have embeded a svg canvas into a composite using SWT_AWT too.
It works fine for me except for the keyboard interactors (ctrl+T and zoom in
and out does not work properly, I don't know why)
here is the code (if you have the solution for the keyboard interactors, by
the way). Note the super(parent, SWT.EMBEDDED); the MaskedSvgCanvas is just
a canvas with additional layers for selection/edition (the canvas is
ALWAYS_DYNAMIC)
/*
* Created on 09.03.2005
*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Style - Code Templates
*/
package com.moow.svg.editor;
import java.awt.BorderLayout;
import java.awt.EventQueue;
import java.awt.Frame;
import java.awt.Panel;
import javax.swing.JRootPane;
import javax.swing.JScrollPane;
import org.eclipse.jface.util.LocalSelectionTransfer;
import org.eclipse.swt.SWT;
import org.eclipse.swt.awt.SWT_AWT;
import org.eclipse.swt.dnd.DND;
import org.eclipse.swt.dnd.DropTarget;
import org.eclipse.swt.dnd.Transfer;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Display;
import org.w3c.dom.svg.SVGDocument;
import com.moow.svg.domain.symbol.GraphicalComponentBean;
import com.moow.svg.toolkit.ui.MaskedSvgCanvas;
import com.moow.svg.toolkit.ui.SvgComponent;
public class SVGComposite extends Composite {
private final MaskedSvgCanvas svgCanvas;
private Frame frame;
private DropTarget dropTarget;
public SVGComposite(Composite parent, int style, boolean showScrollbars,
MaskedSvgCanvas canvas) {
super(parent, SWT.EMBEDDED);
this.svgCanvas = canvas;
parent.setLayout(new FillLayout());
/*
* Set a Windows specific AWT property that prevents heavyweight
* components from erasing their background. Note that this is a global
* property and cannot be scoped. It might not be suitable for your
* application.
*/
try {
System.setProperty("sun.awt.noerasebackground", "true");
} catch (NoSuchMethodError error) {
error.printStackTrace();
}
try {
svgCanvas.setLayout(new BorderLayout());
frame = SWT_AWT.new_Frame(this);
Panel panel = new Panel(new BorderLayout())
{
public void update(java.awt.Graphics g) {
super.update(g);
/* Do not erase the background */
paint(g);
}
};
JRootPane root = new JRootPane();
panel.add(root);
java.awt.Container contentPane = root.getContentPane();
contentPane.setLayout(new BorderLayout());
if (showScrollbars) {
contentPane
.add(BorderLayout.CENTER, new JScrollPane(svgCanvas));
} else {
contentPane.add(BorderLayout.CENTER, svgCanvas);
}
frame.setLayout(new BorderLayout());
frame.add(BorderLayout.CENTER, panel);
frame.setEnabled(true);
} catch (Throwable t) {
t.printStackTrace();
}
}
public void dispose() {
EventQueue.invokeLater(new Runnable() {
public void run() {
try {
frame.dispose();
svgCanvas.dispose();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
super.dispose();
}
public SVGDocument getSVGDocument() {
SVGDocument svgDocument = svgCanvas.getSVGDocument();
if (svgDocument==null)
System.err.println("attention, on a enlevé le svgCanvas.waitIsUsable() et ca
fout la merde!!!");
return svgDocument;
}
public MaskedSvgCanvas getSvgCanvas() {
return svgCanvas;
}
public SvgComponent insertSvgComponent(int x, int y,
GraphicalComponentBean graphicalComponentBean) {
// TODO Auto-generated method stub
return null;
}
public void removeGraphicalComponent(String id) {
// TODO Auto-generated method stub
}
public void makeRegistrations(final SVGCompositeDropListener dropListener) {
Display.getDefault().asyncExec(new Runnable() {
public void run() {
if (dropTarget!=null)
dropTarget.dispose();
int operations = DND.DROP_COPY| DND.DROP_MOVE;
dropTarget = new DropTarget(SVGComposite.this, operations);
dropTarget.setTransfer(new Transfer[]
{LocalSelectionTransfer.getTransfer()});
dropTarget.addDropListener(dropListener);
}
});
}
public void unmakeRegistrations() {
if (dropTarget!=null) {
Display.getDefault().asyncExec(new Runnable() {
@Override
public void run() {
dropTarget.dispose();
dropTarget=null;
}
});
}
}
}
On Thu, Apr 29, 2010 at 12:10 PM, <thomas.dewe...@kodak.com> wrote:
> Hi Michael,
>
> Michael Jurke <ju...@zedat.fu-berlin.de> wrote on 04/27/2010 11:04:34 AM:
>
>
> > I found out there are different problems when using Direct3D or openGL
> > (vm argument -Dsun.java2d.opengl=true) for rendering. Doubled rendering
> > of parts of the image appears with D3D only, with openGL I get some
> > vertical shaking when resizing (not horizontal, strange). Furthermore,
> > moving the shell doesn't update the openGL image - on move yes, but
> > after drawing a line again the image is still where it used to be before
> > the shell's position got changed (can be fixed by an extra listener).
> > It's okay for me to use openGL only, maybe anyone has an idea how to
> > correct the shaking or there might be a better solution when moving the
> > shell?
>
>
> What is "the shell"?
>
> > Finally, still the batik rendering get's stucked, so hopefully
> > anybody has an idea how can I revive it without having to use strange
> > workarounds?
>
> In the updateCompleted method it calls invokeAndWait to update the
> canvas. This is the sort of thing that given potential differences
> between Swing and SWT could lead to a dead lock.
>
>
> > About the code, going throw line by line in different threads, first I
> > found a reason for flickering:
> > AbstractJGVTComponent.paintComponent() calls g2d.fillRect with the
> > background color before painting the image. Why? Wouldn't it be much
> > better to paint on the image first - isn't this meant by double
> > buffering? It seems to be an error.
>
> The Image we draw is often mostly transparent. So we need to draw
> the background color so it can show through the transparent parts of
> the SVG image.
>
> And in any case if this causes flickering then the binding between
> swing and SWT is really badly broken. You shouldn't be able to see
> the 'intermediate' drawing results, I would think you should only see
> the drawing when it's done with the paint method.
>
> > With D3D getRenderRect() sometimes seems to return some wrong values,
> > also the image is not updated properly (results in painting the same
> > image on different locations on small windows). However, as openGL is
> > preferable for us anyway I now have to search the reason for shaking
> > vertically.
>
> I don't see these sorts of problem using just swing so the problem
> must be somewhere in the swing<->SWT translator.
>
> > On 27.04.2010 12:46, thomas.dewe...@kodak.com wrote:
> > > Hi Michael,
> > >
> > > Michael Jurke<ju...@zedat.fu-berlin.de> wrote on 04/27/2010 06:27:11
> AM:
> > >
> > >
> > >> After resizing, batik rendering get's strange behavior. Sometimes, on
> > >> smaller window, parts get rendered doubled on the downside or cheesy
> > >> background stays somehow. Sometimes rendering stucks completely
> although
> > >>
> > >
> > >> the UpdateManager works. Making the window big again, somehow
> magically
> > >> repairs the rendering.
> > >>
> > > If I had to guess something goes bad in the SWT<->Swing connection
> > > on resize. My best guess would be the problem is related to our update
> > > handling. In particular you might look at JSVGComponent in particular
> > > the 'updateCompleted' method (~line 1971). I could imagine that the
> > > 'repaint' and/or paintImmediately could have problems, especially given
> > > the use of invokeAndWait.
> > >
> > > You might see if doing a simple repaint of everything avoids the
> > > issues (this would be less efficient but much more efficient than
> > > setting the whole document).
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
> > For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
> >
>
>
--
Dao Hodac
