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.dewe...@kodak.com [mailto:thomas.dewe...@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" <olivier.ho...@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.magalh...@gmail.com
> <mailto:helder.magalh...@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-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@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-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@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-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@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.
