You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Dennis Hendriks <D....@tue.nl> on 2011/05/10 16:35:13 UTC
Rendering works, most of the time...
Hi all,
For a simulator I'm writing I'm using Batik to visualize the model being
simulated. The simulator loads an SVG file and after each simulation steps,
it calls some hooks that update the SVG document, and after that it redraws
the canvas. The canvas paint event renders the graphics node to a
BufferedImage, after which the data is passed to SWT to render it on the
SWT canvas.
This code constructs the graphics node:
UserAgentAdapter userAgentAdapter = new UserAgentAdapter();
bridgeContext = new BridgeContext(userAgentAdapter);
bridgeContext.setDynamic(true);
GVTBuilder builder = new GVTBuilder();
graphicsNode = builder.build(bridgeContext, document);
Code like this is used to update the document:
elem.setAttribute(attrName, value);
t.setNodeValue(value);
where t is a variable of type Text.
I use graphicsNode.paint(g) to draw on the Graphics2D of the BufferedImage.
This works most of the time, but ever so often (though quite regularly),
graphicsNode.paint(g) does not paint anything. I checked the actual
internal data buffer with pixel data to verify that nothing was painted.
Does anyone know what I might be doing wrong, that causes nothing to be
drawn? Under what circumstances could graphicsNode.paint(g) have the effect
that nothing is drawn?
I used both Batik 1.6 and Batik 1.7, and this 'problem' manifests itself in
both versions. I hope this is enough information. If not, I'd be happy to
provide more info.
Thanks,
Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
[SOLVED] Re: Rendering works, most of the time...
Posted by 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
Re: Rendering works, most of the time...
Posted by Dennis Hendriks <D....@tue.nl>.
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
Re: Rendering works, most of the time...
Posted by th...@kodak.com.
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.
Re: Rendering works, most of the time...
Posted by Dennis Hendriks <D....@tue.nl>.
Hi Thomas,
Thanks for the reply.
> What you say 'canvas' do you mean the Batik JSVGCanvas? Or your
> personsal SWT Canvas?
I only have one canvas, a class derived from the SWT Canvas class. In it's
paint listener I render the graphics node a BufferedImage, and use the
results to draw it on that SWT canvas.
> 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.
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?
> 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.
Best regards,
Dennis
thomas.deweese@kodak.com wrote:
> Hi Dennis,
>
> Dennis Hendriks <D....@tue.nl> wrote on 05/10/2011 10:35:13 AM:
>
> > For a simulator I'm writing I'm using Batik to visualize the model being
> > simulated. The simulator loads an SVG file and after each simulation
> steps,
> > it calls some hooks that update the SVG document, and after that it
> redraws
> > the canvas. The canvas paint event renders the graphics node to a
> > BufferedImage, after which the data is passed to SWT to render it on the
> > SWT canvas.
>
> What you say 'canvas' do you mean the Batik JSVGCanvas? Or your
> personsal SWT Canvas?
>
> > Does anyone know what I might be doing wrong, that causes nothing to be
> > drawn? Under what circumstances could graphicsNode.paint(g) have the
> effect
> > that nothing is drawn?
>
> 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.
>
> The only other thing I can think of would be if the clip (or other
> attributes) of the Graphics2D was weird.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rendering works, most of the time...
Posted by th...@kodak.com.
Hi Dennis,
Dennis Hendriks <D....@tue.nl> wrote on 05/10/2011 10:35:13 AM:
> For a simulator I'm writing I'm using Batik to visualize the model being
> simulated. The simulator loads an SVG file and after each simulation
steps,
> it calls some hooks that update the SVG document, and after that it
redraws
> the canvas. The canvas paint event renders the graphics node to a
> BufferedImage, after which the data is passed to SWT to render it on the
> SWT canvas.
What you say 'canvas' do you mean the Batik JSVGCanvas? Or your
personsal SWT Canvas?
> Does anyone know what I might be doing wrong, that causes nothing to be
> drawn? Under what circumstances could graphicsNode.paint(g) have the
effect
> that nothing is drawn?
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.
The only other thing I can think of would be if the clip (or other
attributes) of the Graphics2D was weird.