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 tes
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
dea
...]
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 o
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
asCache 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 w
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 the
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/[EMAIL PROTECTED]&msgNo=4182
Hi Till, thanks for your message. I did see that earlier posting by
Charlton_Rose, and in fact I am using this techniqu
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 constructin
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 a
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 constructin
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 setS
Thomas DeWeese wrote:
> > I have a map with a bunch of rooms, and what I'm doing is changing
> > the fills in each room to make them different colors, gradients, etc.
> > It's useful to "batch" together all the initial updates that color
> > all the rooms when the map is first loaded.
>
> Sur
Archie Cobbs wrote:
I have a map with a bunch of rooms, and what I'm doing is changing
the fills in each room to make them different colors, gradients, etc.
It's useful to "batch" together all the initial updates that color
all the rooms when the map is first loaded.
Sure you should be able to
t;
> Changes are never made while rendering is occurring. Currently
> when most runnables in the UpdateManager queue complete it checks
> if the rendering tree has any changes. If it doesn't it goes to
> next next runnable.
>
> If it does have changes
d by the same thread in which the actual
manipulation is done? So the next manipulation in the run queue
does not happen until all listeners are notified of the previous
change?
Correct, when the DOM is changed (from the UpdateManager thread)
all effected listeners are called immediately.
Thomas DeWeese wrote:
> > http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=4123
>
> You created a bugzilla entry for this (good job). I responded to
> this requesting a standalone test case. I am keen to fix this but I
> need a test case so I don't just flail around.
Ah
Archie Cobbs wrote:
I sent the two emails below a couple of months ago but got no responses.
So I'm trying again.
I'd greatly appreciate any insights from knowlegable persons.
http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=4123
You created a bugzilla entry for this (good j
I sent the two emails below a couple of months ago but got no responses.
So I'm trying again.
I'd greatly appreciate any insights from knowlegable persons.
http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=4123
http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]&m
There seems to be a bug in the UpdateManager suspend() and resume()
methods in Batik 1.5.1.
The bug is that a thread can invoke and return from both suspend()
and resume() before the suspension has even taken effect, and then
the resume() seems to get lost.
E.g., my code looks like this
Judy Qiu wrote:
Hello,
For the batik SVG viewer, when a UIEvent triggers a piece of JavaScript code
that modifies multiple DOM elements (and eventually changes multiple GVT
nodes accordingly), does the corresponding UpdateManager aware of the
completion of all those graphics node changes before
Hello,
For the batik SVG viewer, when a UIEvent triggers a piece of JavaScript code
that modifies multiple DOM elements (and eventually changes multiple GVT
nodes accordingly), does the corresponding UpdateManager aware of the
completion of all those graphics node changes before the repaint
t should essentially never be synced. So
if you need to call repaint()/resize the document then I suspect
you are making your changes outside of the UpdateManager thread.
Any ideas on the best strategy?
Thanks Again,
Joe
-
To
Thanks for your help, but I realized that I perhaps have been going
about my entire issue wrong. What I want to do is modify a document and
then cause it to repaint. I don't know if setting the canvas to dynamic
mode is the best solution (as this seems to slow thigns down
considerably).
Is there
Joseph Foster wrote:
So I need to modify the DOM of a document and according to the docs the
safe way to do this is to be sure to use the UpdateManager of the Canvas
and add things to the RunnableQueue that it maintains.
My problem is this:
Whenever I attempt to get the UpdateManager from the
So I need to modify the DOM of a document and according to the docs the
safe way to do this is to be sure to use the UpdateManager of the Canvas
and add things to the RunnableQueue that it maintains.
My problem is this:
Whenever I attempt to get the UpdateManager from the canvas
Hi. I have encountered an unusual behavior when dealing with tspan
elements and the Batik UpdateManager. Essentially, I am trying to
change a text label within an SVG file. I have succeeded in changing
the label when the target XML text node is contained within a text
element. However, I have
26 matches
Mail list logo
