Re: Rendering works, most of the time...

Hi Thomas,

Thanks for the quick reply. I'll look into (probably sometime next week), 
and then I'll report back.

Thanks,
Dennis


[email protected] 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 <[email protected]> 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.
> 
>