[SOLVED] Re: Rendering works, most of the time...

[Dennis Hendriks <D....@tue.nl>]

Hi Thomas,

I put a "synchronized(document) { ... }" around both the paint call, as 
well as the call to the callbacks that update the SVG document tree. This 
resolved the issue.

Thanks for helping me out on this.

Best regards,
Dennis


Dennis Hendriks wrote:
> Hi Thomas,
> 
> Thanks for the quick reply. I'll look into (probably sometime next week), 
> and then I'll report back.
> 
> Thanks,
> Dennis
> 
> 
> thomas.deweese@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....@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org