Michael Jurke <firstname.lastname@example.org> 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
> 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
> correct the shaking or there might be a better solution when moving
What is "the shell"?
> Finally, still the batik rendering get's stucked,
> anybody has an idea how can I revive it without having to use strange
In the updateCompleted method it calls
invokeAndWait to update the
canvas. This is the sort of thing that given
between Swing and SWT could lead to a dead lock.
> About the code, going throw line by line in different threads, first
> 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
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
> preferable for us anyway I now have to search the reason for shaking
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, email@example.com
> > Hi Michael,
> > Michael Jurke<firstname.lastname@example.org> wrote on
04/27/2010 06:27:11 AM:
> >> After resizing, batik rendering get's strange behavior. Sometimes,
> >> smaller window, parts get rendered doubled on the downside
> >> background stays somehow. Sometimes rendering stucks completely
> >> the UpdateManager works. Making the window big again, somehow
> >> repairs the rendering.
> > If I had to guess something goes bad in the SWT<->Swing
> > on resize. My best guess would be the problem is related
to our update
> > handling. In particular you might look at JSVGComponent
> > the 'updateCompleted' method (~line 1971). I could imagine
> > 'repaint' and/or paintImmediately could have problems, especially
> > the use of invokeAndWait.
> > You might see if doing a simple repaint of everything
> > issues (this would be less efficient but much more efficient
> > setting the whole document).
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org