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 George Armhold <ar...@cs.rutgers.edu> on 2004/12/09 20:28:52 UTC
accessing UpdateManager before the canvas is displayed
My current understanding of the batik threading model is that one can
expect the UpdateManager to be available once gvtRenderingCompleted
has been fired. This has always worked great for me. But now I am
trying to "prepare" my canvases in advance by constructing them and
calling setSVGDocument before they are made visible on the screen. I
notice that gvtRenderingCompleted is never fired until the canvas is
made visible in some displayed component. Is there some workaround
for this? Would waiting for gvtBuildCompleted suffice, to access the
UpdateManager?
For what it's worth, what I am trying to do here is write a
synchronous version of setSVGDocument- the caller should block until
the doc is fully loaded and ready. (Yes I am taking care not to block
the Swing EDT.)
Thanks for your time.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by George Armhold <ar...@cs.rutgers.edu>.
Archie Cobbs wrote:
> You could add the JSVGCanvas to a JFrame that is never set visible.
> The document should render I think if you say jframe.pack() even
> though you haven't yet said jframe.setVisible().
Hi Archie, thanks for responding. This is what I was thinking of
doing, but was wondering if there is not a cleaner solution through
the Batik API. Having to rely on an unseen frame is probably doable,
but IMHO is kind of a hack. I will try this though if nothing else
better materializes.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by Archie Cobbs <ar...@dellroad.org>.
George Armhold wrote:
> My current understanding of the batik threading model is that one can
> expect the UpdateManager to be available once gvtRenderingCompleted
> has been fired. This has always worked great for me. But now I am
> trying to "prepare" my canvases in advance by constructing them and
> calling setSVGDocument before they are made visible on the screen. I
> notice that gvtRenderingCompleted is never fired until the canvas is
> made visible in some displayed component. Is there some workaround
> for this? Would waiting for gvtBuildCompleted suffice, to access the
> UpdateManager?
>
> For what it's worth, what I am trying to do here is write a
> synchronous version of setSVGDocument- the caller should block until
> the doc is fully loaded and ready. (Yes I am taking care not to block
> the Swing EDT.)
You could add the JSVGCanvas to a JFrame that is never set visible.
The document should render I think if you say jframe.pack() even
though you haven't yet said jframe.setVisible().
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
*
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
*
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by till varoquaux <ti...@laposte.net>.
Hi well if this can help you, you can set the GVTtree of JSVGCanvas
via the setGraphicsNode() methode (of JGVTtreeRendrerer I think).
So this might help you keep on using JSVGCanvases
Cheers
> Hi Till, thanks for your message. I did see that earlier posting by
> Charlton_Rose, and in fact I am using this technique in some places
> for rendering an Image when I already have an existing GVT tree.
> However in this particular case I really do need to work within the
> context of a JSVGCanvas, and Charlton's posting is all about avoiding
> the canvas.
>
> Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by George Armhold <ar...@cs.rutgers.edu>.
till varoquaux wrote:
> I don't have much time for answering but shortely: I had the same
> problems and this
> http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=batik-users@xml.apache.org&msgNo=4182
Hi Till, thanks for your message. I did see that earlier posting by
Charlton_Rose, and in fact I am using this technique in some places
for rendering an Image when I already have an existing GVT tree.
However in this particular case I really do need to work within the
context of a JSVGCanvas, and Charlton's posting is all about avoiding
the canvas.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by till varoquaux <ti...@laposte.net>.
George Armhold wrote:
> My current understanding of the batik threading model is that one can
> expect the UpdateManager to be available once gvtRenderingCompleted
> has been fired. This has always worked great for me. But now I am
> trying to "prepare" my canvases in advance by constructing them and
> calling setSVGDocument before they are made visible on the screen. I
> notice that gvtRenderingCompleted is never fired until the canvas is
> made visible in some displayed component. Is there some workaround
> for this? Would waiting for gvtBuildCompleted suffice, to access the
> UpdateManager?
>
> For what it's worth, what I am trying to do here is write a
> synchronous version of setSVGDocument- the caller should block until
> the doc is fully loaded and ready. (Yes I am taking care not to block
> the Swing EDT.)
>
> Thanks for your time.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
I don't have much time for answering but shortely:
I had the same problems and this
http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=batik-users@xml.apache.org&msgNo=4182
was my solution.
Hope it helps....
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Thomas DeWeese wrote:
>
> > I think the reason the canvas doesn't render is because it's size is
> > zero not because it isn't shown. If you set the canvas size (say to
> > 10x10 or something) before adding the document it should render.
>
> Bingo! With this simple change my unit test now passes, no more
> deadlock. Is there any performance gain to be had by correctly
> predicting the eventual displayed size, vs specifying 10x10?
Yes, potentially. If you get the size right it should (in theory)
be able to use the BufferedImage generated by the render directly
(the new canvas should just 'pop up' essentially no wait).
The question is if something in the processes of getting reparented
and computing a "new" display transform messes up and clears the
current image. I it is worth trying, if it doesn't work it hopefully
shouldn't be too hard to fix.
One word of caution, these buffered images can use up quite a
bit of memory so you wouldn't want to do it for _lots_ of canvases
but have 3 or 4 (with an appropriate JVM size) shouldn't be much of
an issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> I think the reason the canvas doesn't render is because it's size is
> zero not because it isn't shown. If you set the canvas size (say to
> 10x10 or something) before adding the document it should render.
Bingo! With this simple change my unit test now passes, no more
deadlock. Is there any performance gain to be had by correctly
predicting the eventual displayed size, vs specifying 10x10?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Thomas DeWeese wrote:
> > I'm not 100% sure that I understand what you want to do so let me
> > know if I've missed something important.
>
> I want to know when the doc is fully loaded into the canvas, and ready
> for updates by modifying the DOM programmatically. [...]
>
> To keep the rest of my code simple, I wanted my CanvasCache to worry
> about canvas creation and blocking until the UpdateManager is
> available. [...] This way clients of the cache can request and
> immediately use canvases without worrying about whether
> the UpdateManager was ready yet or not.
Well unfortunately the current design of the canvas doesn't support
this without some hacks. The UpdateManager is never available until
after the first rendering. It's worth noting that you may want to
trigger a rendering anyway as some additional work is done during the
first rendering of the tree (for example I think text is actually
laid out during the first render).
> But for this waitUntilLoaded to work, the canvas must first be made
> visible. Which means either I have to fake out Batik by displaying my
> canvas in a hidden frame somewhere, or I have to move push the call up
> into my client code somewhere, which I was hoping to avoid.
I think the reason the canvas doesn't render is because it's
size is zero not because it isn't shown. If you set the canvas size
(say to 10x10 or something) before adding the document it should
render.
---
> > If you want the update manager so you can twiddle the document you
> > can (and should) do this in an onload DOM event handler (perhaps
> > attached after document load) or in one of the svgLoadEventDispatch
> > callbacks (so if you do it in the Completed call you will know that
> > any 'in document' onload handlers have run and completed).
>
> Yes the goal is in fact to twiddle the DOM. But I don't quite
> understand what you mean by "onload DOM event handler"... JavaScript?
Just like you would add a 'onclick' java event listener to
the document you can add a 'onload' java event listener. This is
an opportunity to modify the DOM before the first rendering but this
really isn't what you want.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> If you want the update manager so you can twiddle the document you
> can (and should) do this in an onload DOM event handler (perhaps
> attached after document load) or in one of the svgLoadEventDispatch
> callbacks (so if you do it in the Completed call you will know that
> any 'in document' onload handlers have run and completed).
Yes the goal is in fact to twiddle the DOM. But I don't quite
understand what you mean by "onload DOM event handler"... JavaScript?
> I'm not 100% sure that I understand what you want to do so let me
> know if I've missed something important.
I want to know when the doc is fully loaded into the canvas, and ready
for updates by modifying the DOM programmatically. I have an app
where the user can navigate among several SVG documents. For
performance I would like to line up several canvases and keep them
ready in a cache. When the user navigates to a particular document,
its canvas is added to my frame, and he can then perform various edits
on the doc via Swing actions (funneled into the UpdateManager's
queue.)
To keep the rest of my code simple, I wanted my CanvasCache to worry
about canvas creation and blocking until the UpdateManager is
available. I wrote a simple waitUntilLoaded() method that blocks
waiting for gvtRenderingCompleted. This way clients of the cache can
request and immediately use canvases without worrying about whether
the UpdateManager was ready yet or not. Also since the cache blocks
waiting for each document to be ready, it's able to figure out how
much time is spent loading each doc, and can be somewhat intelligent
about not using too much CPU.
But for this waitUntilLoaded to work, the canvas must first be made
visible. Which means either I have to fake out Batik by displaying my
canvas in a hidden frame somewhere, or I have to move push the call up
into my client code somewhere, which I was hoping to avoid.
Sorry if this explanation has not been succint, I tried my best. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: accessing UpdateManager before the canvas is displayed
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> My current understanding of the batik threading model is that one can
> expect the UpdateManager to be available once gvtRenderingCompleted
> has been fired. This has always worked great for me. But now I am
> trying to "prepare" my canvases in advance by constructing them and
> calling setSVGDocument before they are made visible on the screen. I
> notice that gvtRenderingCompleted is never fired until the canvas is
> made visible in some displayed component. Is there some workaround
> for this?
Perhaps....
> Would waiting for gvtBuildCompleted suffice, to access the
> UpdateManager?
Definitely not.
> For what it's worth, what I am trying to do here is write a
> synchronous version of setSVGDocument- the caller should block until
> the doc is fully loaded and ready. (Yes I am taking care not to block
> the Swing EDT.)
If you are just interested in knowing "the last thing" before
rendering you should wait on the 'svgLoadEventDispatchCompleted'.
At this point however there will not be installed untill the
first rendering completes (after all you can't update something
that doesn't exist).
If you want the update manager so you can twiddle the
document you can (and should) do this in an onload DOM
event handler (perhaps attached after document load) or in one
of the svgLoadEventDispatch callbacks (so if you do it in the
Completed call you will know that any 'in document' onload
handlers have run and completed).
I'm not 100% sure that I understand what you want to do so
let me know if I've missed something important.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org