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 2005/03/15 17:38:04 UTC
Any plans for Java 1.4 in the Batik codebase?
Now that 1.5 has been out for some time, are there any plans to start
allowing 1.4 features into the Batik code base? Are there potential
speedups to be had by using any of the classes included in 1.4's Image
IO framework?
Just curious...
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Any plans for Java 1.4 in the Batik codebase?
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> The real win would likely be in using Image I/O to write images. In
> particular our PNG encoder is extremely slow (I haven't noticed this
> to be a large problem with the decoder but I must admit to not
> testing it too much).
I guess there's nothing to help general rasterization (SVG ->
BufferedImage)?
A somewhat related question- would it be faster to parse/display SVG
in the canvas for documents that refer to external (say gif/jpg)
images vs having the image data embedded into the docs as base64? We
use a third party app that embeds the images in this way... my
(untested) intuition is that external images would be faster.
> In the svg12 branch we already have a code fork for 1.3 vs 1.4 so I
> would expect that as development moves to that branch that new
> 'features' would be enabled for users on JDK 1.4 such as using Image
> I/O for reading images.
Sounds like a logical way to migrate. Maybe some day we will have a
Batik 2.0 that breaks away from the Java 1.3 constraints?
> It should be fairly simple for someone to write a ImageTagRegistry
> Entry that used Image I/O I haven't done so since I didn't think it
> warranted introducing the split for jdk 1.4.
OK I did not know about this API, I will have a look. Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Any plans for Java 1.4 in the Batik codebase?
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Måns Rullgård wrote:
>
> > There are platforms with nothing later than Java 1.3 available.
> > Requiring Java 1.4 might irritate some users of those.
>
> Are there really many people using Batik on Java 1.3? (That's not a
> rhetorical question- I'd really like to know.)
Well, I still mostly use JDK 1.3 but a large part of that is
just to ensure that Batik still works on JDK 1.3. I don't think
this really counts though.
> Also if someone in the know could comment on my question about
> potential performance improvements by using the new APIs in 1.4
> Image IO, I'd appreciate it.
This is a little tricker to know. We currently use the JDK
JPEG decoder so that shouldn't be significantly faster. We
don't use the JDK PNG decoder because it is/was not compliant with
the SVG specification (IIRC it was the way it handled the
gamma chunk, it is possible that this problem could be 'fixed'
with Image IO).
The real win would likely be in using Image I/O to write images.
In particular our PNG encoder is extremely slow (I haven't noticed
this to be a large problem with the decoder but I must admit to
not testing it too much).
In the svg12 branch we already have a code fork for 1.3 vs 1.4
so I would expect that as development moves to that branch that
new 'features' would be enabled for users on JDK 1.4 such as using
Image I/O for reading images.
It should be fairly simple for someone to write a
ImageTagRegistry Entry that used Image I/O I haven't done so
since I didn't think it warranted introducing the split for
jdk 1.4.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Maik Schürer <Ma...@proveo.de>.
Thanks Thomas,
is it possible to check, if UpdateManager has something in his queue ?
Then I can suppress unnecessary invokeLater() calls.
I will do some test with RunnableQueue.iterator()... or is
UpdateManager.isRunning() suitable for me ?
Maik
Thomas DeWeese schrieb:
> Maik Schürer wrote:
>
>>> a e.printStackTrace() to line 773 in CSSEngine.java.
>>
>>
>> Maybe your source code is different
>
>
> Yes, I'm working off CVS, but I took a look at the 1.5.1
> code I am now essentially 100% convinced that you have multiple
> threads touching the DOM.
>
>
>> java.lang.NullPointerException
>> at [...]CSSEngine.putAuthorProperty(CSSEngine.java:1222)
>
>
> For this to happen 'dest' must be null. In the
> 'StyleDeclarationDocumentHandler.property' function:
>
>> at
>> [...]CSSEngine$StyleDeclarationDocumentHandler.property(CSSEngine.java:1408)
>
>
>
> The styleMap data member is passed in. Note that the
> CSSEngine uses one StyleDeclarationDocumentHandler instance
> to parse all 'style' attributes.
>
> Skipping a few stack frames we come to:
>
>> [...].getCascadedStyleMap(CSSEngine.java:782)
>
>
> The code around this exception is:
>
> 779: styleDeclarationDocumentHandler.styleMap = result;
> 780: parser.setDocumentHandler
> 781: (styleDeclarationDocumentHandler);
> 782: parser.parseStyleDeclaration(style);
> 783: styleDeclarationDocumentHandler.styleMap = null;
>
> I'm fairly certain that what you are seeing is that
> some time after thread 1 passes line 779 it get's interrupted
> (probably during parsing) and thread 2 takes over and also
> goes through 779 setting styleMap to it's result, finishes
> parsing and reset's styleMap to 'null' at line 783.
>
> This is really the only way I can see this could happen.
>
>> > Is the top of the stack trace always the updateManager
>> > runnableQueue?
>> Yes, it seems so.
>>
>> Did I use the UpdateManager wrong ?
>
>
> The real question is how to track down who/how this is happening.
> The approach I would use would be to add:
>
> new Error("Setting 'styleMap'").printStackTrace();
>
> Whenever the styleMap is set on the style declaration handler.
> This will spew lots and lots of output but with it you can
> tell exactly what the sequence is and if any other threads are
> getting into the CSSEngine.
>
> ---------------------------------------------------------------------
> 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: irregular DOMException
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Maik,
Maik Schürer wrote:
> where should I add
> new Error("Setting 'styleMap'").printStackTrace();
> ?
> at begin of method getCascadedStyleMap() ?
Anywhere you think is useful, but I would start with
every place the style handler's styleMap is set and
cleared (use "Clearing 'styleMap'" for the clear case
of course).
This will let you see the actual interplay of set/clear
and the threads involved (if it is too much info you
could also just print the thread instance but you will need
to have a way to map those thread instances back to
your code).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Maik Schürer <Ma...@proveo.de>.
where should I add
new Error("Setting 'styleMap'").printStackTrace();
?
at begin of method getCascadedStyleMap() ?
Maik
Thomas DeWeese schrieb:
> Maik Schürer wrote:
>
>>> a e.printStackTrace() to line 773 in CSSEngine.java.
>>
>>
>> Maybe your source code is different
>
>
> Yes, I'm working off CVS, but I took a look at the 1.5.1
> code I am now essentially 100% convinced that you have multiple
> threads touching the DOM.
>
>
>> java.lang.NullPointerException
>> at [...]CSSEngine.putAuthorProperty(CSSEngine.java:1222)
>
>
> For this to happen 'dest' must be null. In the
> 'StyleDeclarationDocumentHandler.property' function:
>
>> at
>> [...]CSSEngine$StyleDeclarationDocumentHandler.property(CSSEngine.java:1408)
>
>
>
> The styleMap data member is passed in. Note that the
> CSSEngine uses one StyleDeclarationDocumentHandler instance
> to parse all 'style' attributes.
>
> Skipping a few stack frames we come to:
>
>> [...].getCascadedStyleMap(CSSEngine.java:782)
>
>
> The code around this exception is:
>
> 779: styleDeclarationDocumentHandler.styleMap = result;
> 780: parser.setDocumentHandler
> 781: (styleDeclarationDocumentHandler);
> 782: parser.parseStyleDeclaration(style);
> 783: styleDeclarationDocumentHandler.styleMap = null;
>
> I'm fairly certain that what you are seeing is that
> some time after thread 1 passes line 779 it get's interrupted
> (probably during parsing) and thread 2 takes over and also
> goes through 779 setting styleMap to it's result, finishes
> parsing and reset's styleMap to 'null' at line 783.
>
> This is really the only way I can see this could happen.
>
>> > Is the top of the stack trace always the updateManager
>> > runnableQueue?
>> Yes, it seems so.
>>
>> Did I use the UpdateManager wrong ?
>
>
> The real question is how to track down who/how this is happening.
> The approach I would use would be to add:
>
> new Error("Setting 'styleMap'").printStackTrace();
>
> Whenever the styleMap is set on the style declaration handler.
> This will spew lots and lots of output but with it you can
> tell exactly what the sequence is and if any other threads are
> getting into the CSSEngine.
>
> ---------------------------------------------------------------------
> 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: irregular DOMException
Posted by Thomas DeWeese <Th...@Kodak.com>.
Maik Schürer wrote:
>> a e.printStackTrace() to line 773 in CSSEngine.java.
>
> Maybe your source code is different
Yes, I'm working off CVS, but I took a look at the 1.5.1
code I am now essentially 100% convinced that you have multiple
threads touching the DOM.
> java.lang.NullPointerException
> at [...]CSSEngine.putAuthorProperty(CSSEngine.java:1222)
For this to happen 'dest' must be null. In the
'StyleDeclarationDocumentHandler.property' function:
> at [...]CSSEngine$StyleDeclarationDocumentHandler.property(CSSEngine.java:1408)
The styleMap data member is passed in. Note that the
CSSEngine uses one StyleDeclarationDocumentHandler instance
to parse all 'style' attributes.
Skipping a few stack frames we come to:
> [...].getCascadedStyleMap(CSSEngine.java:782)
The code around this exception is:
779: styleDeclarationDocumentHandler.styleMap = result;
780: parser.setDocumentHandler
781: (styleDeclarationDocumentHandler);
782: parser.parseStyleDeclaration(style);
783: styleDeclarationDocumentHandler.styleMap = null;
I'm fairly certain that what you are seeing is that
some time after thread 1 passes line 779 it get's interrupted
(probably during parsing) and thread 2 takes over and also
goes through 779 setting styleMap to it's result, finishes
parsing and reset's styleMap to 'null' at line 783.
This is really the only way I can see this could happen.
> > Is the top of the stack trace always the updateManager
> > runnableQueue?
> Yes, it seems so.
>
> Did I use the UpdateManager wrong ?
The real question is how to track down who/how this is happening.
The approach I would use would be to add:
new Error("Setting 'styleMap'").printStackTrace();
Whenever the styleMap is set on the style declaration handler.
This will spew lots and lots of output but with it you can
tell exactly what the sequence is and if any other threads are
getting into the CSSEngine.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Maik Schürer <Ma...@proveo.de>.
Hi Thomas,
> I don't really know what your problem is...
My problem is the appearing batik error panel ;-)
> a e.printStackTrace() to line 773 in CSSEngine.java.
Maybe your source code is different, my line 773 in CSSEngine.java from
http://apache.engram.de/apache.org/xml/batik/batik-src-1.5.1.zip
is
String style = elt.getAttributeNS(styleNamespaceURI, ...
there does not appear the exception, but a little bit later
My appearing exception is the DOMException catched in line 784.
The full stack trace is:
java.lang.NullPointerException
at
org.apache.batik.css.engine.CSSEngine.putAuthorProperty(CSSEngine.java:1222)
at
org.apache.batik.css.engine.CSSEngine$StyleDeclarationDocumentHandler.property(CSSEngine.java:1408)
at
org.apache.batik.css.parser.Parser.parseStyleDeclaration(Parser.java:910)
at
org.apache.batik.css.parser.Parser.parseStyleDeclarationInternal(Parser.java:301)
at
org.apache.batik.css.parser.Parser.parseStyleDeclaration(Parser.java:1711)
at
org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(CSSEngine.java:782)
at
org.apache.batik.css.engine.CSSEngine.invalidateProperties(CSSEngine.java:1941)
at
org.apache.batik.css.engine.CSSEngine.propagateChanges(CSSEngine.java:2086)
at
org.apache.batik.css.engine.CSSEngine.invalidateProperties(CSSEngine.java:1981)
at
org.apache.batik.css.engine.CSSEngine.propagateChanges(CSSEngine.java:2086)
at
org.apache.batik.css.engine.CSSEngine.invalidateProperties(CSSEngine.java:1981)
at
org.apache.batik.css.engine.CSSEngine.inlineStyleAttributeUpdated(CSSEngine.java:1880)
at
org.apache.batik.css.engine.CSSEngine$DOMAttrModifiedListener.handleEvent(CSSEngine.java:2349)
at
org.apache.batik.dom.events.EventSupport.fireEventListeners(EventSupport.java:268)
at
org.apache.batik.dom.events.EventSupport.dispatchEvent(EventSupport.java:240)
at org.apache.batik.dom.AbstractNode.dispatchEvent(AbstractNode.java:455)
at
org.apache.batik.dom.AbstractElement.fireDOMAttrModifiedEvent(AbstractElement.java:547)
at org.apache.batik.dom.AbstractAttr.setNodeValue(AbstractAttr.java:175)
at org.apache.batik.dom.AbstractAttr.setValue(AbstractAttr.java:218)
at
org.apache.batik.dom.AbstractElement.setAttributeNS(AbstractElement.java:276)
at
org.apache.batik.dom.svg.SVGStylableElement$StyleDeclaration.propertyChanged(SVGStylableElement.java:707)
at
org.apache.batik.css.dom.CSSOMStyleDeclaration.setProperty(CSSOMStyleDeclaration.java:189)
at de.proveo.wwt.gui.svgmap.unit.SVGUnit.show(SVGUnit.java:299)
at de.proveo.wwt.gui.svgmap.panels.SVGMapPanel$1.run(SVGMapPanel.java:336)
at org.apache.batik.util.RunnableQueue.run(RunnableQueue.java:207)
at java.lang.Thread.run(Thread.java:536)
> Is the top of the stack trace always the updateManager
> runnableQueue?
Yes, it seems so.
Did I use the UpdateManager wrong ?
Maik
Thomas DeWeese schrieb:
> Hi Maik,
>
> I don't really know what your problem is, I haven't encountered
> anything like this in my experience. My first guess is that some of
> your old code is still not using the update manager/invoke later
> to make changes to the DOM.
>
> You might get a clearer picture of what is going wrong by adding
> a e.printStackTrace() to line 773 in CSSEngine.java.
>
> Is the top of the stack trace always the updateManager
> runnableQueue?
>
> Maik Schürer wrote:
>
>> since I have added update my canvas via getUpdateManager/invokeLater,
>> I get irregular DOMExceptions like that:
>> org.w3c.dom.DOMException: file:...test.svg:
>> The attribute "style" represents an invalid CSS declaration
>> ("fill:rgb(0,0,255);stroke:rgb(0,0,0);stroke-width:1").
>> Original message:
>> at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown
>> Source)
>> ...
>>
>> The line/style, which is criticized, is always different and I think
>> my test.svg is ok.
>>
>> When I remove getUpdateManager/invokeLater, no error panel appears.
>> (But also my changes doesn't appears immediately ;-) )
>> Any ideas ? What did I wrong ?
>> Maik
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: irregular DOMException
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Maik,
I don't really know what your problem is, I haven't encountered
anything like this in my experience. My first guess is that some of
your old code is still not using the update manager/invoke later
to make changes to the DOM.
You might get a clearer picture of what is going wrong by adding
a e.printStackTrace() to line 773 in CSSEngine.java.
Is the top of the stack trace always the updateManager
runnableQueue?
Maik Schürer wrote:
> since I have added update my canvas via getUpdateManager/invokeLater, I
> get irregular DOMExceptions like that:
> org.w3c.dom.DOMException: file:...test.svg:
> The attribute "style" represents an invalid CSS declaration
> ("fill:rgb(0,0,255);stroke:rgb(0,0,0);stroke-width:1").
> Original message:
> at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown
> Source)
> ...
>
> The line/style, which is criticized, is always different and I think my
> test.svg is ok.
>
> When I remove getUpdateManager/invokeLater, no error panel appears.
> (But also my changes doesn't appears immediately ;-) )
> Any ideas ? What did I wrong ?
> Maik
>
>
> ---------------------------------------------------------------------
> 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
irregular DOMException
Posted by Maik Schürer <Ma...@proveo.de>.
Hi there,
since I have added update my canvas via getUpdateManager/invokeLater, I
get irregular DOMExceptions like that:
org.w3c.dom.DOMException: file:...test.svg:
The attribute "style" represents an invalid CSS declaration
("fill:rgb(0,0,255);stroke:rgb(0,0,0);stroke-width:1").
Original message:
at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown Source)
...
The line/style, which is criticized, is always different and I think my
test.svg is ok.
When I remove getUpdateManager/invokeLater, no error panel appears.
(But also my changes doesn't appears immediately ;-) )
Any ideas ? What did I wrong ?
Maik
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Any plans for Java 1.4 in the Batik codebase?
Posted by George Armhold <ar...@cs.rutgers.edu>.
Måns Rullgård wrote:
> There are platforms with nothing later than Java 1.3 available.
> Requiring Java 1.4 might irritate some users of those.
Are there really many people using Batik on Java 1.3? (That's not a
rhetorical question- I'd really like to know.) Also if someone in the
know could comment on my question about potential performance
improvements by using the new APIs in 1.4 Image IO, I'd appreciate it.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Any plans for Java 1.4 in the Batik codebase?
Posted by Måns Rullgård <mr...@inprovide.com>.
George Armhold <ar...@cs.rutgers.edu> writes:
> Now that 1.5 has been out for some time, are there any plans to start
> allowing 1.4 features into the Batik code base? Are there potential
> speedups to be had by using any of the classes included in 1.4's Image
> IO framework?
There are platforms with nothing later than Java 1.3 available.
Requiring Java 1.4 might irritate some users of those.
--
Måns Rullgård
mru@inprovide.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org