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 "HODAC, Olivier" <OL...@airbus.com> on 2009/11/30 10:25:25 UTC
SVG update performances over X11 export display
Hello,
I've written a little mokeup of an animated SVG application. I modify
the document in the thread
getUpdateManager().getUpdateRunnableQueue().invokeLater
but I have several elements to change, and for the moment, I do a lot of
invokeLater. In my local machine, it runs very well. I try an export
display (linux, rhel) and the performances are completely degraded.
Is there a best practice to have good performances with X11 export
display?
Of course, I'll first try to make 1 big invokeLater, unless somebody
says it is pointless...
Olivier Dao Ho Dac
Flight Test Software Architect
Airbus - EVIDA
Phone : + 33 (0)5 67 19 81 34
Fax : +33(0)5 61 93 80 02
Mailto:olivier.hodac@airbus.com
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
Re: SVG update performances over X11 export display
Posted by Helder Magalhães <he...@gmail.com>.
Hi Olivier,
> I modify the
> document in the thread
>
> getUpdateManager().getUpdateRunnableQueue().invokeLater
Good, this is the recommended way [1] for doing it. :-)
> but I have several elements to change, and for the moment, I do a lot of
> invokeLater. In my local machine, it runs very well. I try an export display
> (linux, rhel) and the performances are completely degraded.
>
> Is there a best practice to have good performances with X11 export display?
>
> Of course, I’ll first try to make 1 big invokeLater, unless somebody says it
> is pointless...
I haven't tried to profile myself but making a big document updates is
intuitively quicker: it will cause less document repaints. This
performance benefits is expected independently of hardware/platform,
but naturally it will be noticed whenever there's a bottleneck (in
this case, apparently the display export).
I'm convinced you'll find related posts within the mailing list archives. ;-)
Regards,
Helder
[1] http://xmlgraphics.apache.org/batik/using/scripting/java.html
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG update performances over X11 export display
Posted by Helder Magalhães <he...@gmail.com>.
Hi Olivier,
> Is there a way to do this with the batik framework:
>
> beginBatchModifications()
> thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> endBatch()
>
>
> so that I will not have to manage my synchronized queue of runnable and ensure the repaint is performed by the endBatch?
Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
implements [2]. ;-)
Hope this helps,
Helder
[1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces
[2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGSVGContext.html
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: SVG update performances over X11 export display
Posted by th...@kodak.com.
Hi HODAC,
"HODAC, Olivier" <OL...@airbus.com> wrote on 11/30/2009 10:24:00
AM:
> When I suspendRedraw, my invokeLater calls piles up the runnables in
> the runnableQueue.
This sounds like you are suspending the RunnableQueue not
suspending Redraw. When redraws are suspended the runnables should
run as normal but the repaint operation should be skipped (dirty
regions will accumulate).
> But when I release (unsuspend), what happends?
> I suppose the update manager unpiles the runnables. Does the repaint
> made only once when the queue is empty? It is not clear...
When many runnables are submitted at once the UpdateManager
will not repaint after every one but will repaint fairly frequently
(~50FPS). This behavior is controlled by the MIN_REPAINT_TIME in
the UpdateManager which you can set with the property:
org.apache.batik.min_repaint_time
That said if you can 'logically' group the updates into sets
then suspending redraw and re-enabling it is probably better.
> -----Message d'origine-----
> De : Helder Magalhães [mailto:helder.magalhaes@gmail.com]
> Envoyé : lundi 30 novembre 2009 14:53
> À : batik-users@xmlgraphics.apache.org
> Objet : Re: SVG update performances over X11 export display
>
> Hi Olivier,
>
>
> > Is there a way to do this with the batik framework:
> >
> > beginBatchModifications()
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> > thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> > endBatch()
> >
> >
> > so that I will not have to manage my synchronized queue of
> runnable and ensure the repaint is performed by the endBatch?
>
> Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
> implements [2]. ;-)
>
>
> Hope this helps,
> Helder
>
>
> [1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces
> [2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/
> dom/svg/SVGSVGContext.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
RE: SVG update performances over X11 export display
Posted by th...@kodak.com.
Hi Olivier,
"HODAC, Olivier" <OL...@airbus.com> wrote on 12/01/2009 08:28:55
AM:
> Do you mean that if I set org.apache.batik.min_repaint_time=100ms
> (10 points a sec, this is my requirement) and I call the invokeLater
> with higher frequency(say 50ms), batik will pile up the runnables in
> the queue and poll them 10 times a second?
Sort of, but not quite.
> To better understand, in my example, the costfull redraw will be
> trigged each 100ms and will process 2 runnables each trig?
Probably not. The basic logic is as follows.
When a runnable is completed it checks if there is another runnable
ready to run. If there isn't a runnable to run it updates the canvas.
If there is a runnable to run it checks how "out of date" the canvas
is, if it is greater than min repaint time then it will update the
canvas otherwise it will run the pending runnable.
> Doing this, I will not have to implement the (un)suspensRedraw, is that
true?
Probably not, since I suspect that when the first runnable completes
there won't be another runnable waiting in the queue, so the update
manager will trigger the update.
>
> De : thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> Envoyé : mardi 1 décembre 2009 12:09
> À : batik-users@xmlgraphics.apache.org
> Cc : batik-users@xmlgraphics.apache.org
> Objet : RE: SVG update performances over X11 export display
>
> Hi HODAC,
>
> "HODAC, Olivier" <OL...@airbus.com> wrote on 11/30/2009 10:24:00
AM:
>
> > When I suspendRedraw, my invokeLater calls piles up the runnables in
> > the runnableQueue.
>
> This sounds like you are suspending the RunnableQueue not
> suspending Redraw. When redraws are suspended the runnables should
> run as normal but the repaint operation should be skipped (dirty
> regions will accumulate).
>
> > But when I release (unsuspend), what happends?
> > I suppose the update manager unpiles the runnables. Does the repaint
> > made only once when the queue is empty? It is not clear...
>
> When many runnables are submitted at once the UpdateManager
> will not repaint after every one but will repaint fairly frequently
> (~50FPS). This behavior is controlled by the MIN_REPAINT_TIME in
> the UpdateManager which you can set with the property:
> org.apache.batik.min_repaint_time
>
> That said if you can 'logically' group the updates into sets
> then suspending redraw and re-enabling it is probably better.
>
> > -----Message d'origine-----
> > De : Helder Magalhães [mailto:helder.magalhaes@gmail.com]
> > Envoyé : lundi 30 novembre 2009 14:53
> > À : batik-users@xmlgraphics.apache.org
> > Objet : Re: SVG update performances over X11 export display
> >
> > Hi Olivier,
> >
> >
> > > Is there a way to do this with the batik framework:
> > >
> > > beginBatchModifications()
> > > thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> > > thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> > > thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> > > thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> > > thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> > > endBatch()
> > >
> > >
> > > so that I will not have to manage my synchronized queue of
> > runnable and ensure the repaint is performed by the endBatch?
> >
> > Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
> > implements [2]. ;-)
> >
> >
> > Hope this helps,
> > Helder
> >
> >
> > [1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces
> > [2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/
> > dom/svg/SVGSVGContext.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
> >
> >
> > This mail has originated outside your organization, either from an
> > external partner or the Global Internet.
> > Keep this in mind if you answer this message.
> >
> >
> >
> >
> > The information in this e-mail is confidential. The contents may not
> > be disclosed or used by anyone other than the addressee. Access to
> > this e-mail by anyone else is unauthorised.
> > If you are not the intended recipient, please notify Airbus
> > immediately and delete this e-mail.
> > Airbus cannot accept any responsibility for the accuracy or
> > completeness of this e-mail as it has been sent over public
> > networks. If you have any concerns over the content of this message
> > or its Accuracy or Integrity, please contact Airbus immediately.
> > All outgoing e-mails from Airbus are checked using regularly updated
> > virus scanning software but you should take whatever measures you
> > deem to be appropriate to ensure that this message and any
> > attachments are virus free.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
> >
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
RE: SVG update performances over X11 export display
Posted by "HODAC, Olivier" <OL...@airbus.com>.
Do you mean that if I set org.apache.batik.min_repaint_time=100ms (10 points a sec, this is my requirement) and I call the invokeLater with higher frequency(say 50ms), batik will pile up the runnables in the queue and poll them 10 times a second?
To better understand, in my example, the costfull redraw will be trigged each 100ms and will process 2 runnables each trig?
Doing this, I will not have to implement the (un)suspensRedraw, is that true?
De : thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
Envoyé : mardi 1 décembre 2009 12:09
À : batik-users@xmlgraphics.apache.org
Cc : batik-users@xmlgraphics.apache.org
Objet : RE: SVG update performances over X11 export display
Hi HODAC,
"HODAC, Olivier" <OL...@airbus.com> wrote on 11/30/2009 10:24:00 AM:
> When I suspendRedraw, my invokeLater calls piles up the runnables in
> the runnableQueue.
This sounds like you are suspending the RunnableQueue not
suspending Redraw. When redraws are suspended the runnables should
run as normal but the repaint operation should be skipped (dirty
regions will accumulate).
> But when I release (unsuspend), what happends?
> I suppose the update manager unpiles the runnables. Does the repaint
> made only once when the queue is empty? It is not clear...
When many runnables are submitted at once the UpdateManager
will not repaint after every one but will repaint fairly frequently
(~50FPS). This behavior is controlled by the MIN_REPAINT_TIME in
the UpdateManager which you can set with the property:
org.apache.batik.min_repaint_time
That said if you can 'logically' group the updates into sets
then suspending redraw and re-enabling it is probably better.
> -----Message d'origine-----
> De : Helder Magalhães [mailto:helder.magalhaes@gmail.com <ma...@gmail.com> ]
> Envoyé : lundi 30 novembre 2009 14:53
> À : batik-users@xmlgraphics.apache.org
> Objet : Re: SVG update performances over X11 export display
>
> Hi Olivier,
>
>
> > Is there a way to do this with the batik framework:
> >
> > beginBatchModifications()
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> > thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> > endBatch()
> >
> >
> > so that I will not have to manage my synchronized queue of
> runnable and ensure the repaint is performed by the endBatch?
>
> Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
> implements [2]. ;-)
>
>
> Hope this helps,
> Helder
>
>
> [1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces <http://www.w3.org/TR/SVG/struct.html#DOMInterfaces>
> [2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/ <http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/>
> dom/svg/SVGSVGContext.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
RE: SVG update performances over X11 export display
Posted by "HODAC, Olivier" <OL...@airbus.com>.
Great!
I am watching the sources of Batik, but I cannot get the behaviour:
When I suspendRedraw, my invokeLater calls piles up the runnables in the runnableQueue. But when I release (unsuspend), what happends?
I suppose the update manager unpiles the runnables. Does the repaint made only once when the queue is empty? It is not clear...
-----Message d'origine-----
De : Helder Magalhães [mailto:helder.magalhaes@gmail.com]
Envoyé : lundi 30 novembre 2009 14:53
À : batik-users@xmlgraphics.apache.org
Objet : Re: SVG update performances over X11 export display
Hi Olivier,
> Is there a way to do this with the batik framework:
>
> beginBatchModifications()
> thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> endBatch()
>
>
> so that I will not have to manage my synchronized queue of runnable and ensure the repaint is performed by the endBatch?
Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
implements [2]. ;-)
Hope this helps,
Helder
[1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces
[2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGSVGContext.html
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: SVG update performances over X11 export display
Posted by th...@kodak.com.
Hi Olivier,
"HODAC, Olivier" <OL...@airbus.com> wrote on 12/01/2009 05:18:19
AM:
> I have very bad performances using batik to display and update a SVG
> over a X11 export display. Is there any documentation to understand
> the policy of batik to do the repaint?
No, aside from the source code.
> When I do a setAttribute style, for example, does batik repaints
> only the necessary part of the display (the rectangle surrounding
> the element)?
Batik only updates the parts of the canvas that needs updating.
> If I have several layers, does batik repaints each one?
The question is a bit unclear. When Batik renders a rectangle it
must repaint everything that intersects that rectangle - so if multiple
'layers' intersect that rectangle then they will all be repainted, within
that rectangle. In the end Batik only generates one update region for
swing.
One thing that occurs to me that might be the cause of poor
performance
is the double buffering that Batik does. It's possible that the JVM
ends up sending the entire offscreen buffer to the client. One thing
that might help with that would be to try turning off double buffering in
the Canvas.
The code that renders the Canvas is in batik.swing.gvt.JGVTComponent,
the code that generates the swing updates is in
batik.swing.svg.JSVGComponent
(mostly updateCompleted callback).
I hope that helps.
> -----Message d'origine-----
> De : HODAC, Olivier
> Envoyé : lundi 30 novembre 2009 16:24
> À : batik-users@xmlgraphics.apache.org
> Objet : RE: SVG update performances over X11 export display
>
> Great!
>
> I am watching the sources of Batik, but I cannot get the behaviour:
>
> When I suspendRedraw, my invokeLater calls piles up the runnables in
> the runnableQueue. But when I release (unsuspend), what happends?
> I suppose the update manager unpiles the runnables. Does the repaint
> made only once when the queue is empty? It is not clear...
>
> -----Message d'origine-----
> De : Helder Magalhães [mailto:helder.magalhaes@gmail.com]
> Envoyé : lundi 30 novembre 2009 14:53
> À : batik-users@xmlgraphics.apache.org
> Objet : Re: SVG update performances over X11 export display
>
> Hi Olivier,
>
>
> > Is there a way to do this with the batik framework:
> >
> > beginBatchModifications()
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> > thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> > endBatch()
> >
> >
> > so that I will not have to manage my synchronized queue of
> runnable and ensure the repaint is performed by the endBatch?
>
> Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
> implements [2]. ;-)
>
>
> Hope this helps,
> Helder
>
>
> [1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces
> [2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/
> dom/svg/SVGSVGContext.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
Re: SVG update performances over X11 export display
Posted by Helder Magalhães <he...@gmail.com>.
Hi Olivier,
> I have very bad performances using batik to display and update a SVG over a X11 export display.
I don't know about the internals of X11 export display, but I can
imagine that would be close to Remote Desktop and/or VNC, possibly
more efficient. But given that Java ultimately deals with buffered
images(bitmaps) I guess the X11 export's potential efficiency,
regarding vector operations, is kinda chopped down (please correct me
if I'm wrong!)... It might be possible to implement Batik rendering
directly using X11 primitive operations, which would then take
advantage of the X11 export display, but that would probably be a
crazy project (in terms of the amount of work and required Batik
refactoring)! :-D
> Is there any documentation to understand the policy of batik to do the repaint?
You may take a look at the Batik architecture [1], but that's only a
starting point. The repaint internals are likely within the GVT
module, but I'm not sure if, else than the Javadoc (and the source
code itself, naturally), more documentation is available...
> When I do a setAttribute style, for example, does batik repaints only the necessary
> part of the display (the rectangle surrounding the element)?
That should be the case.
> If I have several layers, does batik repaints each one?
I guess not. As far as I know, the repaint is made by areas so, if you
update the several layers in a single operation -- or using a batch
operation with the already stated (un)suspendRedraw -- than a single
repaint would be expected.
Thomas is the GVT expert [2] so he may be able to shed some light
here; as for me, this is hitting the limit of my current Batik
internals knowledge, so I really doubt I can provide much more useful
information.
As a side note, why not place some debug output in the repaint classes
and check what Batik is doing for yourself...? ;-)
Hope this helps,
Helder
[1] http://xmlgraphics.apache.org/batik/using/architecture.html
[2] http://xmlgraphics.apache.org/batik/contributors.html#expertise
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: SVG update performances over X11 export display
Posted by th...@kodak.com.
Hi Olivier,
"HODAC, Olivier" <OL...@airbus.com> wrote on 12/01/2009 08:23:17
AM:
> The double buffering trick seems to be a good lead. By giving me the
> source classes, do you mean that I will have to modify the batik
> source code to turn off double buffering?
You do not need to modify the code to turn off double buffering.
You can use JSVGCanvas.setDoubleBufferedRendering(false) - note that
this is quite different from turning off Swing's double buffering
(as you were doing in a different message).
The real reason I pointed you at the code was because I give this
a small chance to fix your problem. So you may need to play with
the code to discover a better fix.
> De : thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
> Envoyé : mardi 1 décembre 2009 12:27
> À : batik-users@xmlgraphics.apache.org
> Cc : batik-users@xmlgraphics.apache.org
> Objet : RE: SVG update performances over X11 export display
>
> Hi Olivier,
>
> "HODAC, Olivier" <OL...@airbus.com> wrote on 12/01/2009 05:18:19
AM:
>
> > I have very bad performances using batik to display and update a SVG
> > over a X11 export display. Is there any documentation to understand
> > the policy of batik to do the repaint?
>
> No, aside from the source code.
>
> > When I do a setAttribute style, for example, does batik repaints
> > only the necessary part of the display (the rectangle surrounding
> > the element)?
>
> Batik only updates the parts of the canvas that needs updating.
>
> > If I have several layers, does batik repaints each one?
>
> The question is a bit unclear. When Batik renders a rectangle it
> must repaint everything that intersects that rectangle - so if multiple
> 'layers' intersect that rectangle then they will all be repainted,
within
> that rectangle. In the end Batik only generates one update region for
> swing.
>
> One thing that occurs to me that might be the cause of poor
performance
> is the double buffering that Batik does. It's possible that the JVM
> ends up sending the entire offscreen buffer to the client. One thing
> that might help with that would be to try turning off double buffering
in
> the Canvas.
>
> The code that renders the Canvas is in
batik.swing.gvt.JGVTComponent,
> the code that generates the swing updates is in
batik.swing.svg.JSVGComponent
> (mostly updateCompleted callback).
>
> I hope that helps.
>
> > -----Message d'origine-----
> > De : HODAC, Olivier
> > Envoyé : lundi 30 novembre 2009 16:24
> > À : batik-users@xmlgraphics.apache.org
> > Objet : RE: SVG update performances over X11 export display
> >
> > Great!
> >
> > I am watching the sources of Batik, but I cannot get the behaviour:
> >
> > When I suspendRedraw, my invokeLater calls piles up the runnables in
> > the runnableQueue. But when I release (unsuspend), what happends?
> > I suppose the update manager unpiles the runnables. Does the repaint
> > made only once when the queue is empty? It is not clear...
> >
> > -----Message d'origine-----
> > De : Helder Magalhães [mailto:helder.magalhaes@gmail.com]
> > Envoyé : lundi 30 novembre 2009 14:53
> > À : batik-users@xmlgraphics.apache.org
> > Objet : Re: SVG update performances over X11 export display
> >
> > Hi Olivier,
> >
> >
> > > Is there a way to do this with the batik framework:
> > >
> > > beginBatchModifications()
> > > thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> > > thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> > > thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> > > thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> > > thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> > > endBatch()
> > >
> > >
> > > so that I will not have to manage my synchronized queue of
> > runnable and ensure the repaint is performed by the endBatch?
> >
> > Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
> > implements [2]. ;-)
> >
> >
> > Hope this helps,
> > Helder
> >
> >
> > [1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces
> > [2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/
> > dom/svg/SVGSVGContext.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
> >
> >
> > This mail has originated outside your organization, either from an
> > external partner or the Global Internet.
> > Keep this in mind if you answer this message.
> >
> >
> >
> >
> > The information in this e-mail is confidential. The contents may not
> > be disclosed or used by anyone other than the addressee. Access to
> > this e-mail by anyone else is unauthorised.
> > If you are not the intended recipient, please notify Airbus
> > immediately and delete this e-mail.
> > Airbus cannot accept any responsibility for the accuracy or
> > completeness of this e-mail as it has been sent over public
> > networks. If you have any concerns over the content of this message
> > or its Accuracy or Integrity, please contact Airbus immediately.
> > All outgoing e-mails from Airbus are checked using regularly updated
> > virus scanning software but you should take whatever measures you
> > deem to be appropriate to ensure that this message and any
> > attachments are virus free.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
> >
> >
> > This mail has originated outside your organization, either from an
> > external partner or the Global Internet.
> > Keep this in mind if you answer this message.
> >
> >
> >
> >
> > The information in this e-mail is confidential. The contents may not
> > be disclosed or used by anyone other than the addressee. Access to
> > this e-mail by anyone else is unauthorised.
> > If you are not the intended recipient, please notify Airbus
> > immediately and delete this e-mail.
> > Airbus cannot accept any responsibility for the accuracy or
> > completeness of this e-mail as it has been sent over public
> > networks. If you have any concerns over the content of this message
> > or its Accuracy or Integrity, please contact Airbus immediately.
> > All outgoing e-mails from Airbus are checked using regularly updated
> > virus scanning software but you should take whatever measures you
> > deem to be appropriate to ensure that this message and any
> > attachments are virus free.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
> >
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
RE: SVG update performances over X11 export display
Posted by "HODAC, Olivier" <OL...@airbus.com>.
The double buffering trick seems to be a good lead. By giving me the source classes, do you mean that I will have to modify the batik source code to turn off double buffering?
De : thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
Envoyé : mardi 1 décembre 2009 12:27
À : batik-users@xmlgraphics.apache.org
Cc : batik-users@xmlgraphics.apache.org
Objet : RE: SVG update performances over X11 export display
Hi Olivier,
"HODAC, Olivier" <OL...@airbus.com> wrote on 12/01/2009 05:18:19 AM:
> I have very bad performances using batik to display and update a SVG
> over a X11 export display. Is there any documentation to understand
> the policy of batik to do the repaint?
No, aside from the source code.
> When I do a setAttribute style, for example, does batik repaints
> only the necessary part of the display (the rectangle surrounding
> the element)?
Batik only updates the parts of the canvas that needs updating.
> If I have several layers, does batik repaints each one?
The question is a bit unclear. When Batik renders a rectangle it
must repaint everything that intersects that rectangle - so if multiple
'layers' intersect that rectangle then they will all be repainted, within
that rectangle. In the end Batik only generates one update region for
swing.
One thing that occurs to me that might be the cause of poor performance
is the double buffering that Batik does. It's possible that the JVM
ends up sending the entire offscreen buffer to the client. One thing
that might help with that would be to try turning off double buffering in
the Canvas.
The code that renders the Canvas is in batik.swing.gvt.JGVTComponent,
the code that generates the swing updates is in batik.swing.svg.JSVGComponent
(mostly updateCompleted callback).
I hope that helps.
> -----Message d'origine-----
> De : HODAC, Olivier
> Envoyé : lundi 30 novembre 2009 16:24
> À : batik-users@xmlgraphics.apache.org
> Objet : RE: SVG update performances over X11 export display
>
> Great!
>
> I am watching the sources of Batik, but I cannot get the behaviour:
>
> When I suspendRedraw, my invokeLater calls piles up the runnables in
> the runnableQueue. But when I release (unsuspend), what happends?
> I suppose the update manager unpiles the runnables. Does the repaint
> made only once when the queue is empty? It is not clear...
>
> -----Message d'origine-----
> De : Helder Magalhães [mailto:helder.magalhaes@gmail.com <ma...@gmail.com> ]
> Envoyé : lundi 30 novembre 2009 14:53
> À : batik-users@xmlgraphics.apache.org
> Objet : Re: SVG update performances over X11 export display
>
> Hi Olivier,
>
>
> > Is there a way to do this with the batik framework:
> >
> > beginBatchModifications()
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> > thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> > endBatch()
> >
> >
> > so that I will not have to manage my synchronized queue of
> runnable and ensure the repaint is performed by the endBatch?
>
> Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
> implements [2]. ;-)
>
>
> Hope this helps,
> Helder
>
>
> [1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces <http://www.w3.org/TR/SVG/struct.html#DOMInterfaces>
> [2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/ <http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/>
> dom/svg/SVGSVGContext.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
RE: SVG update performances over X11 export display
Posted by "HODAC, Olivier" <OL...@airbus.com>.
Well, first feedback disabling the double buffering : ugly!
javax.swing.RepaintManager.currentManager(null).setDoubleBufferingEnabled(false);
In display local or export mode, The canvas flikrs and beautiful white rects quickly appears. It actually demonstrates that batik updates only the necessary parts, as the white rects are over the regions to repaint.
I am wondering if JAVA is a good solution since I will export the display. Do you know an other way to export the display of several linux stations on the same monitor?
I have several hosts that will compute the canvas, and my user needs to have the different canvas on the same screen (side by side or on top of each other)
De : thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com]
Envoyé : mardi 1 décembre 2009 12:27
À : batik-users@xmlgraphics.apache.org
Cc : batik-users@xmlgraphics.apache.org
Objet : RE: SVG update performances over X11 export display
Hi Olivier,
"HODAC, Olivier" <OL...@airbus.com> wrote on 12/01/2009 05:18:19 AM:
> I have very bad performances using batik to display and update a SVG
> over a X11 export display. Is there any documentation to understand
> the policy of batik to do the repaint?
No, aside from the source code.
> When I do a setAttribute style, for example, does batik repaints
> only the necessary part of the display (the rectangle surrounding
> the element)?
Batik only updates the parts of the canvas that needs updating.
> If I have several layers, does batik repaints each one?
The question is a bit unclear. When Batik renders a rectangle it
must repaint everything that intersects that rectangle - so if multiple
'layers' intersect that rectangle then they will all be repainted, within
that rectangle. In the end Batik only generates one update region for
swing.
One thing that occurs to me that might be the cause of poor performance
is the double buffering that Batik does. It's possible that the JVM
ends up sending the entire offscreen buffer to the client. One thing
that might help with that would be to try turning off double buffering in
the Canvas.
The code that renders the Canvas is in batik.swing.gvt.JGVTComponent,
the code that generates the swing updates is in batik.swing.svg.JSVGComponent
(mostly updateCompleted callback).
I hope that helps.
> -----Message d'origine-----
> De : HODAC, Olivier
> Envoyé : lundi 30 novembre 2009 16:24
> À : batik-users@xmlgraphics.apache.org
> Objet : RE: SVG update performances over X11 export display
>
> Great!
>
> I am watching the sources of Batik, but I cannot get the behaviour:
>
> When I suspendRedraw, my invokeLater calls piles up the runnables in
> the runnableQueue. But when I release (unsuspend), what happends?
> I suppose the update manager unpiles the runnables. Does the repaint
> made only once when the queue is empty? It is not clear...
>
> -----Message d'origine-----
> De : Helder Magalhães [mailto:helder.magalhaes@gmail.com <ma...@gmail.com> ]
> Envoyé : lundi 30 novembre 2009 14:53
> À : batik-users@xmlgraphics.apache.org
> Objet : Re: SVG update performances over X11 export display
>
> Hi Olivier,
>
>
> > Is there a way to do this with the batik framework:
> >
> > beginBatchModifications()
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> > thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> > thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> > thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> > endBatch()
> >
> >
> > so that I will not have to manage my synchronized queue of
> runnable and ensure the repaint is performed by the endBatch?
>
> Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
> implements [2]. ;-)
>
>
> Hope this helps,
> Helder
>
>
> [1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces <http://www.w3.org/TR/SVG/struct.html#DOMInterfaces>
> [2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/ <http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/>
> dom/svg/SVGSVGContext.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> This mail has originated outside your organization, either from an
> external partner or the Global Internet.
> Keep this in mind if you answer this message.
>
>
>
>
> The information in this e-mail is confidential. The contents may not
> be disclosed or used by anyone other than the addressee. Access to
> this e-mail by anyone else is unauthorised.
> If you are not the intended recipient, please notify Airbus
> immediately and delete this e-mail.
> Airbus cannot accept any responsibility for the accuracy or
> completeness of this e-mail as it has been sent over public
> networks. If you have any concerns over the content of this message
> or its Accuracy or Integrity, please contact Airbus immediately.
> All outgoing e-mails from Airbus are checked using regularly updated
> virus scanning software but you should take whatever measures you
> deem to be appropriate to ensure that this message and any
> attachments are virus free.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
RE: SVG update performances over X11 export display
Posted by "HODAC, Olivier" <OL...@airbus.com>.
Hello,
I have very bad performances using batik to display and update a SVG over a X11 export display. Is there any documentation to understand the policy of batik to do the repaint?
When I do a setAttribute style, for example, does batik repaints only the necessary part of the display (the rectangle surrounding the element)?
If I have several layers, does batik repaints each one?
Etc...
-----Message d'origine-----
De : HODAC, Olivier
Envoyé : lundi 30 novembre 2009 16:24
À : batik-users@xmlgraphics.apache.org
Objet : RE: SVG update performances over X11 export display
Great!
I am watching the sources of Batik, but I cannot get the behaviour:
When I suspendRedraw, my invokeLater calls piles up the runnables in the runnableQueue. But when I release (unsuspend), what happends?
I suppose the update manager unpiles the runnables. Does the repaint made only once when the queue is empty? It is not clear...
-----Message d'origine-----
De : Helder Magalhães [mailto:helder.magalhaes@gmail.com]
Envoyé : lundi 30 novembre 2009 14:53
À : batik-users@xmlgraphics.apache.org
Objet : Re: SVG update performances over X11 export display
Hi Olivier,
> Is there a way to do this with the batik framework:
>
> beginBatchModifications()
> thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
> thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
> thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
> thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
> thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
> endBatch()
>
>
> so that I will not have to manage my synchronized queue of runnable and ensure the repaint is performed by the endBatch?
Well, SVG has the "(un)suspendRedraw" [1] methods, which Batik
implements [2]. ;-)
Hope this helps,
Helder
[1] http://www.w3.org/TR/SVG/struct.html#DOMInterfaces
[2] http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/svg/SVGSVGContext.html
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: SVG update performances over X11 export display
Posted by "HODAC, Olivier" <OL...@airbus.com>.
Of course...
Actually, I have several concurrent threads that wants to modify the document (by delegating the modification to the UpdateRunnableQueue)
Is there a way to do this with the batik framework:
beginBatchModifications()
thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)
endBatch()
so that I will not have to manage my synchronized queue of runnable and ensure the repaint is performed by the endBatch?
-----Message d'origine-----
De : Helder Magalhães [mailto:helder.magalhaes@gmail.com]
Envoyé : lundi 30 novembre 2009 11:07
À : batik-users@xmlgraphics.apache.org
Objet : Re: SVG update performances over X11 export display
Hi Olivier,
> I modify the
> document in the thread
>
> getUpdateManager().getUpdateRunnableQueue().invokeLater
Good, this is the recommended way [1] for doing it. :-)
> but I have several elements to change, and for the moment, I do a lot of
> invokeLater. In my local machine, it runs very well. I try an export display
> (linux, rhel) and the performances are completely degraded.
>
> Is there a best practice to have good performances with X11 export display?
>
> Of course, I'll first try to make 1 big invokeLater, unless somebody says it
> is pointless...
I haven't tried to profile myself but making a big document updates is
intuitively quicker: it will cause less document repaints. This
performance benefits is expected independently of hardware/platform,
but naturally it will be noticed whenever there's a bottleneck (in
this case, apparently the display export).
I'm convinced you'll find related posts within the mailing list archives. ;-)
Regards,
Helder
[1] http://xmlgraphics.apache.org/batik/using/scripting/java.html
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
This mail has originated outside your organization, either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org