Hi Olivier,
"HODAC, Olivier" <olivier.ho...@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.dewe...@kodak.com [mailto:thomas.dewe...@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" <olivier.ho...@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.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.
