Hi Olivier, "HODAC, Olivier" <olivier.ho...@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.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] > > 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-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.
