xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HODAC, Olivier" <OLIVIER.HO...@airbus.com>
Subject RE: SVG update performances over X11 export display
Date Mon, 30 Nov 2009 10:35:53 GMT
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:

thread1 -> getUpdateRunnableQueue().invokeLater(runnable1)
thread2 -> getUpdateRunnableQueue().invokeLater(runnable2)
thread3 -> getUpdateRunnableQueue().invokeLater(runnable3)
thread2 -> getUpdateRunnableQueue().invokeLater(runnable4)
thread1 -> getUpdateRunnableQueue().invokeLater(runnable5)

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. ;-)


[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

View raw message