Hi Michael,

Michael Jurke <jurke@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.deweese@kodak.com wrote:
> > Hi Michael,
> >
> > Michael Jurke<jurke@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org