Hi Thomas,
Thanks for the quick reply. I'll look into (probably sometime next week),
and then I'll report back.
Thanks,
Dennis
thomas.dewe...@kodak.com wrote:
Hi Dennis,
> > It is essential that you not modify the document while a paint is in
> > progress. If the renderer detects this condition it will generaly
abort
> > since it's impossible to get a reasonable result.
Dennis Hendriks <d.hendr...@tue.nl> wrote on 05/12/2011 06:39:46 AM:
> Is there a standard way to avoid rendering while updating? I tried using
> the update manager, but this did not solve the problems. Since the
> simulator is in a different thread than the SWT display, the drawing and
> updating happen in different threads. Does Batik offer something to
solve
> this, or should I apply standard Java thread data sharing techniques?
Well, in the JSVGCanvas we use the UpdateManager and it's
associated
events with the ImageRenderer to manage the offscreen BufferedImages that
are actually displayed in the Swing. There are some potentially
significant
advantages to using this infrastructure as it tracks diry regions and only
updates the areas that are changed. That said plugging in is not trivial
and could probably use significant refactoring.
As far as the simulator being in a different thread than the SWT
display
goes. The way to view the problem is that the rendering of the document
and the updating of the document must be serialized. What the update
manager does is says all modifications will happen in the thread it
controls
(so your simulator might have to send runnables to it rather than directly
updating the document), and when needed it will trigger a render of the
document to an offscreen image. The update manager can then notify the
SWT component that there is a new image to display which can then be
displayed at the SWT threads convenience. Note that somewhere in there
you probably want to swap offscreen buffers so that updates to the GUI
half way through a render don't produce weird results.
> > The only other thing I can think of would be if the clip (or other
> > attributes) of the Graphics2D was weird.
>
> I don't manually change any clipping or related things. I assume
there is
> no way these things change on their own. Also, it works most of the
time,
> but not all the time, so I guess paint while updating would be the more
> likely candidate.
I only mentioned this since your write up made it sound as if the
updates and rendering were serialized in the simulator. If they aren't
that is almost 100% certain to be the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
