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 Jorg Heymans <jh...@domek.be> on 2005/03/20 22:32:59 UTC
canvas resize - nodes gone
Hi,
I am dynamically adding path elements to a document. They show up fine.
However when the canvas is resized everything from the canvas
disappears, even though i've set a viewbox on the document and a fixed
size on the swing component the canvas is embedded in. All other
operations that repaint like zoom, pan are all fine.
Is there a setting on jsvgcanvas i need to set for this to be correct?
Do i need to associate an SVGUserAgent on the canvas perhaps?
Thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Jorg Heymans wrote:
>> An updated viewbox is for example
>> 423463.2 -5470604.7 133015.10000000003 113988.29999999981
>
>
> As I suspected the range is vastly different. Another possible
> workaround would be to set 'recenterOnResize' to false on the
> canvas (canvas.setRecenterOnResize(false)). I think this will
> solve the problem if my suspicions are correct.
It solves the problem yes, but it doesn't look pretty. I'll probably go
for the other workaround you suggested.
Thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
> This brings up an idea I've thought would be useful: an SVG optimizer.
> This would be a class that takes SVG as input, "optimizes" it in
> various ways, and spits it back out. This would do things like:
>
> - Consolidate path elements
> - Remove redundant attributes
> - Consolidate similar attribute values on children to one attribute
> on a parent, from which the child nodes can all inherit.
Very interesting idea. It could be added as another transcoder
(Optimizer Transcoder ???) either DOM to DOM or DOM to XML
Something to add
- remove unnecessary empty text node
Best Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Archie Cobbs <ar...@dellroad.org>.
Jorg Heymans wrote:
>> - Consolidate path elements
>
> This made me thinking, is there a efficient way to consolidate path
> elements without losing the ability to distinguish them for events like
> mouseover, mouseclick etc ?
I don't think so. Mouse events are at the granularity of SVG
elements AFAIK.
>> - Remove redundant attributes
>> - Consolidate similar attribute values on children to one attribute
>> on a parent, from which the child nodes can all inherit.
>
> Does this affect rendering speed ? You mean like complex transforms on
> child nodes that are overwritten by transforms of the parent node ?
I was thinking of simple stuff like a redundant "fill" or "stroke"
attribute. But some attributes have a bigger effect than others
of course.
Another one is to remove unnecessary "enable-background" attributes,
as these cause the renderer to do extra work, etc.
We'd have to do a full analysis of all the possibilities, which itself
would be a major learning experience :-)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Archie Cobbs wrote:
> This brings up an idea I've thought would be useful: an SVG optimizer.
> This would be a class that takes SVG as input, "optimizes" it in
> various ways, and spits it back out. This would do things like:
>
> - Consolidate path elements
This made me thinking, is there a efficient way to consolidate path
elements without losing the ability to distinguish them for events like
mouseover, mouseclick etc ?
> - Remove redundant attributes
> - Consolidate similar attribute values on children to one attribute
> on a parent, from which the child nodes can all inherit.
Does this affect rendering speed ? You mean like complex transforms on
child nodes that are overwritten by transforms of the parent node ?
I like the idea :) Some sort of SVG analyzer that could tell you about
common performance killers and then effectively go ahead and fix it as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Archie Cobbs <ar...@dellroad.org>.
Thomas DeWeese wrote:
> Unfortunately dealing with 10,000 path elements is just going
> to take a while. I will mention that if you can combine path
> elements into one more complex path element (using 'M' commands
> between what used to be separate elements for example) this can make a
> _very_ significant difference in performance (both building and
> rendering).
This brings up an idea I've thought would be useful: an SVG optimizer.
This would be a class that takes SVG as input, "optimizes" it in
various ways, and spits it back out. This would do things like:
- Consolidate path elements
- Remove redundant attributes
- Consolidate similar attribute values on children to one attribute
on a parent, from which the child nodes can all inherit.
Etc.
Right now this is just an idea but someday I'd like to work on it.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Archie Cobbs <ar...@dellroad.org>.
Thomas DeWeese wrote:
>> I'm not sure what the Client.access$7 means during data appending,
>> does this signify a different thread? It seems to point to a line
>> where i am fetching the updated data from the documentfragment.
>
> I think this indicates some sort of anonymous inner class reference
> (constructor?).
It's probably a compiler-induced "access trampoline" which is required
when you use private inner classes. If you make your inner classes
package access then it will go away. But in any case it doesn't hurt.
> Well I would start tracking graphics nodes being added/removed
> from the GVT tree. This is mostly managed by the BridgeContext
> in the DOMNodeInserted/RemovedEventListeners. It flows out
> from there.
>
> What is the form of the Logo in SVG? Just a 'G' and SVG elem
> or a 'use'?
Probably not useful, but I've seen with certain Sun JDK installations that
don't have fonts configured properly text will sometimes disappear for
no reason. FWIW.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
> Update:
>
> By carefully commenting and uncommenting code i narrowed the problem
> down to this line where i search the new data for a particular node:
>
> // root is an element that was created off the main SVG document using
> // getSVGDocument().createElementNS(null,"myns:newdata")
> Node n = XPathAPI.selectSingleNode(root, "//*[@id='" + id + "']");
>
> Uncommenting this line makes the canvas behave consistent again.
^^^^^^^^^^^^
Do you mean "commenting"?
> How can XPathAPI possibly influence the canvas in this way?
It is hard for me to guess. Is this code run outside of the
UpdateManager Thread?
> Granted it searches a node that was created using the main SVG
> document, but that node is never appended to the main document.
There are some global structures that are associated with
the owner document. My guess would be that these get corrupted
(especially if the access is multi-threaded).
> Does anyone know of a better way to search for a node by attribute ID
> starting from a certain parent Node?
batik.dom.AbstractDocument.getChildElementById(Node n, String id)
Or you can use SVGSVGElement.getElementById(String id)
These will search the document fragment that they are called in
relation to. So the entire subtree associated with 'n' or the svg
element is searched but this seems what you want. My suggestion
would be to use the 'svg' element. BTW the code above you gave
a prefix "myns" but didn't provide a namespace - which is a little
hokey.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> What is the form of the Logo in SVG? Just a 'G' and SVG elem
> or a 'use'?
It's a plain old <g> element.
Update:
By carefully commenting and uncommenting code i narrowed the problem
down to this line where i search the new data for a particular node:
// root is an element that was created off the main SVG document using
// getSVGDocument().createElementNS(null,"myns:newdata")
Node n = XPathAPI.selectSingleNode(root, "//*[@id='" + id + "']");
Uncommenting this line makes the canvas behave consistent again.
How can XPathAPI possibly influence the canvas in this way? Granted it
searches a node that was created using the main SVG document, but that
node is never appended to the main document.
Does anyone know of a better way to search for a node by attribute ID
starting from a certain parent Node?
Regards
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
Sorry, I don't have much in the way of ideas...
Jorg Heymans wrote:
> Stack during logo removal
Looks ok to me...
> Stack during data appending
Also looks ok.
> Thread [RunnableQueue-0] (Suspended (breakpoint at line 329 in Client))
> Client.updateMap(MapUpdate) line: 329
> Client.access$7(Client, MapUpdate) line: 300
> I'm not sure what the Client.access$7 means during data appending, does
> this signify a different thread? It seems to point to a line where i am
> fetching the updated data from the documentfragment.
I think this indicates some sort of anonymous inner class reference
(constructor?).
>> When the GVT tree is modified outside of the update manager thread
> Yes but if this is the case than my appended data wouldn't show at all
> would it ?
Well as soon as you talk about multiple threads just about anything
can happen. The stack traces seem to indicate that this is probably
not the case.
> Anything lowlevel i can do to get to the bottom of this?
Well I would start tracking graphics nodes being added/removed
from the GVT tree. This is mostly managed by the BridgeContext
in the DOMNodeInserted/RemovedEventListeners. It flows out
from there.
What is the form of the Logo in SVG? Just a 'G' and SVG elem
or a 'use'?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Hi Jorg,
>
>> Can I do anything else to debug this? What would cause an element that
>> is physically removed the DOM to still appear on the canvas?
>
>
> Well my best guess is that you have a threading issue, you've
> already stated that this isn't a problem but I still suspect it is
> (of course I've been wrong before).
>
> You might try printing out the current stack trace before you
> remove the logo and before you add the content and make sure they are
> rooted in the UpdateManager's RunnableQueue.
Stack during logo removal
Thread [RunnableQueue-0] (Suspended (breakpoint at line 211 in Client$4))
Client$4.run() line: 211
RunnableQueue.run() line: 199
HaltingThread(Thread).run() line: 534
Stack during data appending
Thread [RunnableQueue-0] (Suspended (breakpoint at line 329 in Client))
Client.updateMap(MapUpdate) line: 329
Client.access$7(Client, MapUpdate) line: 300
Client$4.run() line: 228
RunnableQueue.run() line: 199
HaltingThread(Thread).run() line: 534
Both are in the RunnableQueue, i switch to it using
getUpdateManager().getUpdateRunnableQueue().invokeLater(new Runnable()...)
I'm not sure what the Client.access$7 means during data appending, does
this signify a different thread? It seems to point to a line where i am
fetching the updated data from the documentfragment.
>
> When the GVT tree is modified outside of the update manager thread
> (implying that the DOM is being modified outside of the update manager
> thread) you will get the 'disappears' for the next rendering behavior
> you are seeing.
Yes but if this is the case than my appended data wouldn't show at all
would it ?
Anything lowlevel i can do to get to the bottom of this?
Thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
I'm still playing around with it, maybe the following is stil useful:
- when i resize the canvas *after* the initial logo is displayed, then
the logo disappears when i append the data.
- when i resize the canvas *before* the initial logo is displayed then
the problem appears again.
It seems that batik does not now that the logo is there until it somehow
has to repaint the canvas.
Regards
Jorg
Thomas DeWeese wrote:
> Hi Jorg,
>
> Jorg Heymans wrote:
>
>> I can't seem to isolate the problem, which probably indicates
>> something smelly is going on with my DOM (remember the attribute
>> namespaces!).
>
>
>> Can I do anything else to debug this? What would cause an element that
>> is physically removed the DOM to still appear on the canvas?
>
>
> Well my best guess is that you have a threading issue, you've
> already stated that this isn't a problem but I still suspect it is
> (of course I've been wrong before).
>
> You might try printing out the current stack trace before you
> remove the logo and before you add the content and make sure they are
> rooted in the UpdateManager's RunnableQueue.
>
> When the GVT tree is modified outside of the update manager thread
> (implying that the DOM is being modified outside of the update manager
> thread) you will get the 'disappears' for the next rendering behavior
> you are seeing.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
Jorg Heymans wrote:
> I can't seem to isolate the problem, which probably indicates something
> smelly is going on with my DOM (remember the attribute namespaces!).
> Can I do anything else to debug this? What would cause an element that
> is physically removed the DOM to still appear on the canvas?
Well my best guess is that you have a threading issue, you've
already stated that this isn't a problem but I still suspect it is
(of course I've been wrong before).
You might try printing out the current stack trace before you
remove the logo and before you add the content and make sure they are
rooted in the UpdateManager's RunnableQueue.
When the GVT tree is modified outside of the update manager thread
(implying that the DOM is being modified outside of the update manager
thread) you will get the 'disappears' for the next rendering behavior
you are seeing.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
I can't seem to isolate the problem, which probably indicates something
smelly is going on with my DOM (remember the attribute namespaces!).
Can I do anything else to debug this? What would cause an element that
is physically removed the DOM to still appear on the canvas?
Thanks
Jorg
Jorg Heymans wrote:
>
>
> Thomas DeWeese wrote:
>
>>
>> I'm guessing that you know this but all you need to do is
>> removeChild the logo element. Mucking with it's children
>> isn't doing anything useful, this shouldn't cause the
>> problem of course.
>
>
> Yeah, i had removeChild() only at first, but was thinking this could
> make a difference somehow.
>
> I'll see about getting you a standalone example.
>
> Thanks
> Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
>
> I'm guessing that you know this but all you need to do is
> removeChild the logo element. Mucking with it's children
> isn't doing anything useful, this shouldn't cause the
> problem of course.
Yeah, i had removeChild() only at first, but was thinking this could
make a difference somehow.
I'll see about getting you a standalone example.
Thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
>
> Thomas DeWeese wrote:
>
>> Hi Jorg,
>>
>>> Result: the new paths are now displayed properly but the logo is
>>> being displayed as well still. I checked the DOM tree and it's
>>> effectively gone there. With the next redraw (eg canvas resize or
>>> something) the logo disappears.
>>
>> I don't suppose you can reproduce this?
>
> It happens every time.
I meant in a standalone example.
>> I'm having a hard time understanding how you could possibly
>> get this result if 2a happened before 2b in the UpdateManger
>> thread.
>
> There is some odd behaviour though, because even when i set the node in
> question to hidden before i remove it, it is still displayed. Only when
> i set it to hidden and don't remove it it is not displayed anymore.
I'm guessing that you know this but all you need to do is
removeChild the logo element. Mucking with it's children
isn't doing anything useful, this shouldn't cause the
problem of course.
> Element logo = getSVGDocument().getElementById("logo");
> if (logo != null) {
> logo.setAttributeNS(null, "visibility", "hidden");
> while (logo.hasChildNodes()) {
> logo.removeChild(logo.getFirstChild());
> }
> // remove the logo
> logo.getParentNode().removeChild(logo);
> }
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Hi Jorg,
>
>> Result: the new paths are now displayed properly but the logo is being
>> displayed as well still. I checked the DOM tree and it's effectively
>> gone there. With the next redraw (eg canvas resize or something) the
>> logo disappears.
>
>
> I don't suppose you can reproduce this?
It happens every time.
> It sounds to me like a race condition are 2a/b done
> together in the code or could the be done in different
> threads (not update thread?) or something?
The removal code and the update code happen in the same updatemanager
thread, nearly sequentially.
>
> I'm having a hard time understanding how you could possibly
> get this result if 2a happened before 2b in the UpdateManger
> thread.
There is some odd behaviour though, because even when i set the node in
question to hidden before i remove it, it is still displayed. Only when
i set it to hidden and don't remove it it is not displayed anymore.
Element logo = getSVGDocument().getElementById("logo");
if (logo != null) {
logo.setAttributeNS(null, "visibility", "hidden");
while (logo.hasChildNodes()) {
logo.removeChild(logo.getFirstChild());
}
// remove the logo
logo.getParentNode().removeChild(logo);
}
Regards
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
Jorg Heymans wrote:
> I have a small issue with your viewbox fix btw. Again my situation :
>
> 1. display a logo in viewbox 0 0 800 600
> 2a. remove the logo <g> element
> 2b. get paths from server, set the viewbox on the document to something
> like 423463.2 -5470604.7 133015 113988, then append the new paths
> Result: the new paths are now displayed properly but the logo is being
> displayed as well still. I checked the DOM tree and it's effectively
> gone there. With the next redraw (eg canvas resize or something) the
> logo disappears.
I don't suppose you can reproduce this?
> Thoughts?
It sounds to me like a race condition are 2a/b done
together in the code or could the be done in different
threads (not update thread?) or something?
I'm having a hard time understanding how you could possibly
get this result if 2a happened before 2b in the UpdateManger
thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
>
> Replace:
>
> <path d="M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
> <path d="M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
>
> With:
>
> <path d="M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
> M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
>
i see now thanks. We will adjust our datasets to collapse several paths
into one.
I have a small issue with your viewbox fix btw. Again my situation :
1. display a logo in viewbox 0 0 800 600
2a. remove the logo <g> element
2b. get paths from server, set the viewbox on the document to something
like 423463.2 -5470604.7 133015 113988, then append the new paths
Result: the new paths are now displayed properly but the logo is being
displayed as well still. I checked the DOM tree and it's effectively
gone there. With the next redraw (eg canvas resize or something) the
logo disappears.
Thoughts?
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
> Thomas DeWeese wrote:
>> I will mention that if you can combine path
>> elements into one more complex path element (using 'M' commands
>> between what used to be separate elements for example) this can make a
>> _very_ significant difference in performance (both building and
>> rendering).
Jorg Heymans wrote:
> Could you elaborate a bit ? say we have 10 path elements like this one
>
> <path d="M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
>
> How would i use the M command to speed up things?
Replace:
<path d="M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
<path d="M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
With:
<path d="M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
One Path element with both sets of points.
For this to work the two path elements have to have the same
drawing style, and of course you lose the ability to easily
distinguish the two paths (based on mouse over or what ever).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
>
>
> Unfortunately dealing with 10,000 path elements is just going
> to take a while. I will mention that if you can combine path
> elements into one more complex path element (using 'M' commands
> between what used to be separate elements for example) this can make a
> _very_ significant difference in performance (both building and
> rendering).
Could you elaborate a bit ? say we have 10 path elements like this one
<path d="M 920081 -5691558.6 l -18.7 557 -464.1 185.3 286.4 274.2 ...
How would i use the M command to speed up things?
>
>> Unfortunately, i only create this second svg element once. Subsequent
>> updates are always appended to this element.
>
>
> I would remove the second SVG from the document then make all my
> changes and append the result back into the document.
ok i'll try this.
> Since they reorg the mailing-lists the commit mails are going to
> xml-batik-cvs@apache.org I was under the impression that everyone
> people subscribed to dev were subscribed to this list as well but
> you might try subscribing.
i'm "subscribed" through gmane, and i do get all other emails on dev@,
wierd.
Thanks for your help
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
> Thomas DeWeese wrote:
>> BTW one other point things will be a tad bit more efficient
>> if you append your content under the child svg and then append
>> the svg to the document (rather than appending the svg and then
>> appending your content to the svg).
Jorg Heymans wrote:
> why is this? I am very much interested in any efficiency gains !
> (At the moment we are trying to optimize performance when appending
> about 10000 path elements to the DOM tree so any other tips about
> possible performance/efficiency gains are well appreciated)
The best thing to do for 'large scale' changes is do all your
changes out of the main tree and append/replaceChild the result.
Unfortunately dealing with 10,000 path elements is just going
to take a while. I will mention that if you can combine path
elements into one more complex path element (using 'M' commands
between what used to be separate elements for example) this can make a
_very_ significant difference in performance (both building and
rendering).
> Unfortunately, i only create this second svg element once. Subsequent
> updates are always appended to this element.
I would remove the second SVG from the document then make all my
changes and append the result back into the document.
> PS I didn't see the commit over on dev@, are commit emails disabled ATM?
Since they reorg the mailing-lists the commit mails are going to
xml-batik-cvs@apache.org I was under the impression that everyone
people subscribed to dev were subscribed to this list as well but
you might try subscribing.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
>
> This is because your root SVG doesn't have a width/height
> and viewBox (doesn't really matter what the viewBox is but it
> needs to have one - width & height are a little optional but
> still a good idea).
>
> Also my CVS commit this morning should fix the viewBox problem
> anyways.
cool ! I'll try it out now.
> BTW one other point things will be a tad bit more efficient
> if you append your content under the child svg and then append
> the svg to the document (rather than appending the svg and then
> appending your content to the svg).
why is this? I am very much interested in any efficiency gains !
(At the moment we are trying to optimize performance when appending
about 10000 path elements to the DOM tree so any other tips about
possible performance/efficiency gains are well appreciated)
Unfortunately, i only create this second svg element once. Subsequent
updates are always appended to this element.
Thanks
Jorg
PS I didn't see the commit over on dev@, are commit emails disabled ATM?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
> Thomas DeWeese wrote:
>
>>>> This can be done by simply creating the element:
>>>> <svg x="0" y="0" width="100%" height="100%" viewBox="# # # #">
>>>> and appending your new content under it.
Jorg Heymans wrote:
> This workaround works but has one drawback : the
> resetRenderingTransform() doesn't work anymore. I can reproduce it by
> resizing the canvas, pan around a bit, then do reset..(). Batik puts the
> graphic where it was before the canvas was resized.
This is because your root SVG doesn't have a width/height
and viewBox (doesn't really matter what the viewBox is but it
needs to have one - width & height are a little optional but
still a good idea).
Also my CVS commit this morning should fix the viewBox problem
anyways.
BTW one other point things will be a tad bit more efficient
if you append your content under the child svg and then append
the svg to the document (rather than appending the svg and then
appending your content to the svg).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
<snip/>
>>> This can be done by simply creating the element:
>>> <svg x="0" y="0" width="100%" height="100%" viewBox="# # # #">
>>> and appending your new content under it.
This workaround works but has one drawback : the
resetRenderingTransform() doesn't work anymore. I can reproduce it by
resizing the canvas, pan around a bit, then do reset..(). Batik puts the
graphic where it was before the canvas was resized.
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
>> Then when it goes to updateRenderingTransform it get's a bit confused.
>>
>> Probably the best way to work around this problem would be for you
>> to create a new SVG element rather than update the root SVG element.
>>
>> This can be done by simply creating the element:
>> <svg x="0" y="0" width="100%" height="100%" viewBox="# # # #">
>> and appending your new content under it.
>
>
> This is a workaround, but i've got code like
> getSVGDocument().getRootElement().getScreenCTM().inverse().getE();
> , which will produce invalid numbers after I modify the viewbox in a
> different element, right ?
Yes, but this is easily fixed by adding an 'id' to the new
svg element and replacing 'getRootelement' with getElementById('foo')
(where 'foo' is the id on your new SVG).
>> I'm trying to think of good solutions to the underlying problem.
>> Can you give me a ball park figure for the 'updated' viewBox coords?
>> I'd like try and produce a simple standalone example of the problem.
>
> An updated viewbox is for example
> 423463.2 -5470604.7 133015.10000000003 113988.29999999981
As I suspected the range is vastly different. Another possible
workaround would be to set 'recenterOnResize' to false on the
canvas (canvas.setRecenterOnResize(false)). I think this will
solve the problem if my suspicions are correct.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
>
> Ok, I think I know what is happening. The canvas 'caches' a
> copy of the viewingTransform so it doesn't have to go into the
> UpdateManagerThread to access it everytime. The problem is that
> when you change the viewBox this copy is now invalid.
makes sense.
>
> Then when it goes to updateRenderingTransform it get's a bit confused.
>
> Probably the best way to work around this problem would be for you
> to create a new SVG element rather than update the root SVG element.
>
> This can be done by simply creating the element:
> <svg x="0" y="0" width="100%" height="100%" viewBox="# # # #">
> and appending your new content under it.
This is a workaround, but i've got code like
getSVGDocument().getRootElement().getScreenCTM().inverse().getE();
, which will produce invalid numbers after I modify the viewbox in a
different element, right ?
>
> I'm trying to think of good solutions to the underlying problem.
> Can you give me a ball park figure for the 'updated' viewBox coords?
> I'd like try and produce a simple standalone example of the problem.
An updated viewbox is for example
423463.2 -5470604.7 133015.10000000003 113988.29999999981
Thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
> The situation :
> upon application start a static svg is loaded from the filesystem. This
> is nothing more then a colored rect, the root element has viewbox like 0
> 0 800 600
>
> What i am doing :
> upon rect-click, retrieve path elements from server and add them to the
> document for display. The path elements have coordinates in a specific
> viewbox, this viewbox is transmitted from the server as well. Before i
> add the elements i modify the viewBox attr of the root element with the
> new viewBox.
> When i now resize the canvas the path elements briefly show the correct
> new position, then the canvas shows nothing anymore.
Ok, I think I know what is happening. The canvas 'caches' a
copy of the viewingTransform so it doesn't have to go into the
UpdateManagerThread to access it everytime. The problem is that
when you change the viewBox this copy is now invalid.
Then when it goes to updateRenderingTransform it get's a bit confused.
Probably the best way to work around this problem would be for you
to create a new SVG element rather than update the root SVG element.
This can be done by simply creating the element:
<svg x="0" y="0" width="100%" height="100%" viewBox="# # # #">
and appending your new content under it.
I'm trying to think of good solutions to the underlying problem.
Can you give me a ball park figure for the 'updated' viewBox coords?
I'd like try and produce a simple standalone example of the problem.
> What does work :
> - if i set the correct viewbox in the static svg already, then the
> canvas still shows my path elements after resize. Note that i still
> replace the viewbox attribute in the document, i just replace with an
> identical viewbox so there are no real changes.
>
> What does not work :
> - set viewbox (ie change it), then add elements
>
>
> I hope this clarifies my situation.
>
> Regards
> Jorg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Jorg Heymans wrote:
>
>>>> The funny thing is that the component is redrawn correctly first but
>>>> then everything disappears immediately afer. I'll have a look at
>>>> that method, thanks.
>>
>>
>> Well i can "correct" the behaviour by setting a correct viewbox first
>> before i start manipulating the document. The viewbox is set
>> dynamically before any other manipulation, so this could be where the
>> problem lays.
>
>
> I don't think I follow what works and what doesn't. In the working
> case you set the viewBox before building the GVT tree? Or is it just
> where in the dynamic case that you set the viewBox?
>
> If you can summarize working/non-working cases I might have
> suggestions on what could be the problem.
The situation :
upon application start a static svg is loaded from the filesystem. This
is nothing more then a colored rect, the root element has viewbox like 0
0 800 600
What i am doing :
upon rect-click, retrieve path elements from server and add them to the
document for display. The path elements have coordinates in a specific
viewbox, this viewbox is transmitted from the server as well. Before i
add the elements i modify the viewBox attr of the root element with the
new viewBox.
When i now resize the canvas the path elements briefly show the correct
new position, then the canvas shows nothing anymore.
What does work :
- if i set the correct viewbox in the static svg already, then the
canvas still shows my path elements after resize. Note that i still
replace the viewbox attribute in the document, i just replace with an
identical viewbox so there are no real changes.
What does not work :
- set viewbox (ie change it), then add elements
I hope this clarifies my situation.
Regards
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jorg Heymans wrote:
>>> The funny thing is that the component is redrawn correctly first but
>>> then everything disappears immediately afer. I'll have a look at that
>>> method, thanks.
>
> Well i can "correct" the behaviour by setting a correct viewbox first
> before i start manipulating the document. The viewbox is set dynamically
> before any other manipulation, so this could be where the problem lays.
I don't think I follow what works and what doesn't. In the working
case you set the viewBox before building the GVT tree? Or is it just
where in the dynamic case that you set the viewBox?
If you can summarize working/non-working cases I might have
suggestions on what could be the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Jorg Heymans wrote:
>
>> The funny thing is that the component is redrawn correctly first but
>> then everything disappears immediately afer. I'll have a look at that
>> method, thanks.
>
Well i can "correct" the behaviour by setting a correct viewbox first
before i start manipulating the document. The viewbox is set dynamically
before any other manipulation, so this could be where the problem lays.
I rolled back to CVS 18-11-2004 but it didn't make a difference, same
behaviour.
Thoughts?
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
> Thomas DeWeese wrote:
>> Do you have any 'onZoom' or 'onPan' event handlers?
>> I ask because everything for the resize should be done when
>> the first repaint occurs. So something must be triggering a
>> second repaint.
Jorg Heymans wrote:
> I didn't install any handlers no. Where can i see source of the
> updateevents that are being triggered?
Tap into the RunnableQueue.invokeLater/invokeAndWait
and print the stack trace.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
>
> Do you have any 'onZoom' or 'onPan' event handlers?
> I ask because everything for the resize should be done when
> the first repaint occurs. So something must be triggering a
> second repaint.
I didn't install any handlers no. Where can i see source of the
updateevents that are being triggered?
Thanks
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
>
> Do you have any 'onZoom' or 'onPan' event handlers?
> I ask because everything for the resize should be done when
> the first repaint occurs. So something must be triggering a
> second repaint.
I can confirm the second repaint though, the updatemanagerlistener
receives 2 update started and update completed events for each resize,
which seems odd to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
>
> Thomas DeWeese wrote:
>>
>> Not that I can think of. Tthe main method that is called
>> when the canvas is resized is updateRenderingTransform.
>> You might want to see what that is doing.
Jorg Heymans wrote:
> The funny thing is that the component is redrawn correctly first but
> then everything disappears immediately afer. I'll have a look at that
> method, thanks.
Do you have any 'onZoom' or 'onPan' event handlers?
I ask because everything for the resize should be done when
the first repaint occurs. So something must be triggering a
second repaint.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Jorg Heymans <jh...@domek.be>.
Thomas DeWeese wrote:
> Hi Jorg,
>
> Not that I can think of. Tthe main method that is called
> when the canvas is resized is updateRenderingTransform.
> You might want to see what that is doing.
The funny thing is that the component is redrawn correctly first but
then everything disappears immediately afer. I'll have a look at that
method, thanks.
Regards
Jorg
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: canvas resize - nodes gone
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jorg,
Jorg Heymans wrote:
> I am dynamically adding path elements to a document. They show up fine.
> However when the canvas is resized everything from the canvas
> disappears, even though i've set a viewbox on the document and a fixed
> size on the swing component the canvas is embedded in. All other
> operations that repaint like zoom, pan are all fine.
>
> Is there a setting on jsvgcanvas i need to set for this to be correct?
No.
> Do i need to associate an SVGUserAgent on the canvas perhaps?
Not that I can think of. Tthe main method that is called
when the canvas is resized is updateRenderingTransform.
You might want to see what that is doing.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org