Hi again,
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? 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?
Or already a solution for me - if anybody has an idea - where how to
know whether rendering got stucked, it would be very, very great!!! So I
could check and call setDocument only when there is a problem.
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.
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.
Thanks a lot for any help!
Regards
Michael
On 27.04.2010 12:46, [email protected] wrote:
Hi Michael,
Michael Jurke<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
