xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Rendering works, most of the time...
Date Thu, 12 May 2011 12:34:33 GMT
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.Hendriks@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.



Mime
View raw message