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 "Pepping, Florian" <fl...@wincor-nixdorf.com> on 2008/11/28 13:24:27 UTC

Some current batik observations

Hi Helder,

we had a conversation about bug-reports of batik a few days ago
(animation issues).
Now, I just want to give a small comment on the current batik version in
trunk.

I reported, that the mentioned bugs seem to be solved. That's
furthermore correct.
However, the overall situation concerning performance of animations and
other functions
of batik seems to have decreased at the moment.
We tested the (self-builded) trunk version in our application for a few
days, but we have
to step back to the 1.7 version. That's because of many exceptions occur
(concurrent modification,
missing fields and some other) and the animations are somewhat
unaccurate and slow.
Concrete bugs or reports for bugs are not available.

This mail shall not be any complaint or something like a bug report.
It's just a observation of the
current situation. Perhaps this information may be helpful, otherwise
just leave it anywhere.

Thanks and greetings

Florian Pepping






-- 
WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Gesch�ftsf�hrer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. J�rgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enth�lt vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt�mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


RE: Some current batik observations

Posted by "Pepping, Florian" <fl...@wincor-nixdorf.com>.
Hi Helder,

having a look at the codesnippet below, you can see, that the exception raised is not caused by a Null-Reference on the UpdateManager but because something within the getAnimationEngine-Method is null. However this is not in the scope of our code.

BTW:
Testing the UpdateManager not to be null like the way below, is a fairly common way. There may be some very special situations, in which this test is not enough (havily multithreaded environments, changing the tested variable very often) but in this use case this test should be ok.
We initalize the variable at programm startup and nothing else ever happens with it again.


As I though a wile, the UpdateManager of Batik is the counterpart to the SwingUtilities.invokeLater-Method. The UpdateManager gets some updates to be performed and it decides when to execute these updates. The programmer must have no knowledge about the current execution situation of Batik.

Correct me if I'm wrong with this statement.

Thanks for your help

Florian


// stop animation engine, if any
UpdateManager updateMgr = this.getUpdateManager();
if (updateMgr != null)
{
  try
  {
      BridgeContext bridgeContext = updateMgr.getBridgeContext();
      AnimationEngine animationEngine = bridgeContext.getAnimationEngine();
      animationEngine.pause();
  }
  catch (Exception e)
  {
      logger.log(Level.WARNING, "Error JSVGCanvas kickoffTransition", e);
  }
}

java.lang.NullPointerException
	at org.apache.batik.bridge.SVGAnimationEngine.<init>(Unknown Source) [batik-all-jar-1.8.jar:1.8pre+r]
	at org.apache.batik.bridge.BridgeContext.getAnimationEngine(BridgeContext.java:726) [batik-all-jar-1.8.jar:1.8pre+r]
	.... (non batik code) 



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Florian Pepping                         Wincor Nixdorf International GmbH
Banking Division                        Product Development (PSD5)
Phone: +49 5251 693 6471                Heinz-Nixdorf-Ring 1
Fax: +49 5251 693 6309                  D-33106 Paderborn
florian.pepping@wincor-nixdorf.com      http://www.wincor-nixdorf.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 



-----Original Message-----
From: Helder Magalhães [mailto:helder.magalhaes@gmail.com] 
Sent: Monday, January 12, 2009 10:39 PM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Some current batik observations

> Hello Helder,

Hi Florian! :-)


I've just had a quick glance on the code (no real attempts on
reproducing the exception) and I still have a feeling that the problem
is a thread-unsafe operations (link on thread-safe recommendations in
previous message):

> if (updateMgr != null) //maybe not null here...
> {
>  try
>  {
        //... but maybe null here! who knows? ;-D
>      BridgeContext bridgeContext = updateMgr.getBridgeContext();
>      AnimationEngine animationEngine = bridgeContext.getAnimationEngine();
>      animationEngine.pause();
>  }


My Java skills are pretty low but I guess one can't assume that, in a
multi-threaded environment, update manager will be available during
the whole invocation. That's why it seems that the code portion should
be within an "invokeLater" (or similar). Or am I missing something?
;-)


> Perhaps you can extract some problems there.
>
> Thanks

As stated, my Java knowledge doesn't allow me to go much further.
Aside from this preliminary guess, if following the recommended method
to manipulate the document still raises the exception (please post a
follow-up if so), than maybe someone else can shed some light on
this... :-)


> Florian Pepping

Hope this helps,

 Helder Magalhães

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


-- 
WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Re: Some current batik observations

Posted by Helder Magalhães <he...@gmail.com>.
> Hello Helder,

Hi Florian! :-)


I've just had a quick glance on the code (no real attempts on
reproducing the exception) and I still have a feeling that the problem
is a thread-unsafe operations (link on thread-safe recommendations in
previous message):

> if (updateMgr != null) //maybe not null here...
> {
>  try
>  {
        //... but maybe null here! who knows? ;-D
>      BridgeContext bridgeContext = updateMgr.getBridgeContext();
>      AnimationEngine animationEngine = bridgeContext.getAnimationEngine();
>      animationEngine.pause();
>  }


My Java skills are pretty low but I guess one can't assume that, in a
multi-threaded environment, update manager will be available during
the whole invocation. That's why it seems that the code portion should
be within an "invokeLater" (or similar). Or am I missing something?
;-)


> Perhaps you can extract some problems there.
>
> Thanks

As stated, my Java knowledge doesn't allow me to go much further.
Aside from this preliminary guess, if following the recommended method
to manipulate the document still raises the exception (please post a
follow-up if so), than maybe someone else can shed some light on
this... :-)


> Florian Pepping

Hope this helps,

 Helder Magalhães

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


RE: Some current batik observations

Posted by "Pepping, Florian" <fl...@wincor-nixdorf.com>.
Hello Helder,

this morning I was able to reactivate Batik 1.8 pre in our application, because some other problems have been fixed.
The concurrent modification exception is not reproducable at the moment, but there is another exception occuring:

Using the following code, the exception below occurs.

// stop animation engine, if any
UpdateManager updateMgr = this.getUpdateManager();
if (updateMgr != null)
{
  try
  {
      BridgeContext bridgeContext = updateMgr.getBridgeContext();
      AnimationEngine animationEngine = bridgeContext.getAnimationEngine();
      animationEngine.pause();
  }
  catch (Exception e)
  {
      logger.log(Level.WARNING, "Error JSVGCanvas kickoffTransition", e);
  }
}

java.lang.NullPointerException
	at org.apache.batik.bridge.SVGAnimationEngine.<init>(Unknown Source) [batik-all-jar-1.8.jar:1.8pre+r]
	at org.apache.batik.bridge.BridgeContext.getAnimationEngine(BridgeContext.java:726) [batik-all-jar-1.8.jar:1.8pre+r]
	.... (non batik code)

Perhaps you can extract some problems there.

Thanks

Florian Pepping

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Florian Pepping                         Wincor Nixdorf International GmbH
Banking Division                        Product Development (PSD5)
Phone: +49 5251 693 6471                Heinz-Nixdorf-Ring 1
Fax: +49 5251 693 6309                  D-33106 Paderborn
florian.pepping@wincor-nixdorf.com      http://www.wincor-nixdorf.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 


-----Original Message-----
From: Helder Magalhães [mailto:helder.magalhaes@gmail.com] 
Sent: Friday, November 28, 2008 2:55 PM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Some current batik observations

Hi Florian Pepping,

> However, the overall situation concerning performance of animations and
> other functions of batik seems to have decreased at the moment.
> We tested the (self-builded) trunk version in our application for a few
> days, but we have
> to step back to the 1.7 version. That's because of many exceptions occur
> (concurrent modification,
> missing fields and some other) and the animations are somewhat
> unaccurate and slow.

It would be great if you could share a few example which would
demonstrate the potential regressions, specially regarding
performance. I recall a couple of changes which could take up a small
additional overhead, but nothing relevant. The concurrent modification
issues is definitely worth a better analysis, specially if you are
already following the thread-safe recommendations [1] and/or have
looked into potential issues within the FAQ [2].


> Perhaps this information may be helpful, otherwise
> just leave it anywhere.

As state, the information will be increasingly helpful as more
details/test cases are provided. Please consider reducing and sharing
a few test cases and/or more details: this may, inclusively, help you
find bugs and/or architecture problems which may be haunting your own
application... ;-)


> Thanks and greetings
>
> Florian Pepping

Cheers,

 Helder Magalhães


[1] http://xmlgraphics.apache.org/batik/using/scripting/java.html#N1002A
[2] http://xmlgraphics.apache.org/batik/faq.html#N10203

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


-- 
WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


RE: Some current batik observations

Posted by "Pepping, Florian" <fl...@wincor-nixdorf.com>.
Hi Helder,

I've taken some time to produce some test cases showing the problems I mentioned.
To see the problems, load the provided SVG's both in Squiggle 1.7 and Squiggle 1.8pre (the trunk version).

You see, that the animations are very slow and choppy and not so smooth as in Batik 1.7.

Regarding the concurrent modification exception, I'm not able to reproduce the exception at the moment, because we already stepped back to batik 1.7.
Perhaps I'm able to reproduce the exception, when I've got time to test our application with Batik 18.pre again.

Thanks for your help

Cheers

Florian Pepping

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Florian Pepping                         Wincor Nixdorf International GmbH
Banking Division                        Product Development (PSD5)
Phone: +49 5251 693 6471                Heinz-Nixdorf-Ring 1
Fax: +49 5251 693 6309                  D-33106 Paderborn
florian.pepping@wincor-nixdorf.com      http://www.wincor-nixdorf.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

-----Original Message-----
From: Helder Magalhães [mailto:helder.magalhaes@gmail.com] 
Sent: Friday, November 28, 2008 2:55 PM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Some current batik observations

Hi Florian Pepping,

> However, the overall situation concerning performance of animations and
> other functions of batik seems to have decreased at the moment.
> We tested the (self-builded) trunk version in our application for a few
> days, but we have
> to step back to the 1.7 version. That's because of many exceptions occur
> (concurrent modification,
> missing fields and some other) and the animations are somewhat
> unaccurate and slow.

It would be great if you could share a few example which would
demonstrate the potential regressions, specially regarding
performance. I recall a couple of changes which could take up a small
additional overhead, but nothing relevant. The concurrent modification
issues is definitely worth a better analysis, specially if you are
already following the thread-safe recommendations [1] and/or have
looked into potential issues within the FAQ [2].


> Perhaps this information may be helpful, otherwise
> just leave it anywhere.

As state, the information will be increasingly helpful as more
details/test cases are provided. Please consider reducing and sharing
a few test cases and/or more details: this may, inclusively, help you
find bugs and/or architecture problems which may be haunting your own
application... ;-)


> Thanks and greetings
>
> Florian Pepping

Cheers,

 Helder Magalhães


[1] http://xmlgraphics.apache.org/batik/using/scripting/java.html#N1002A
[2] http://xmlgraphics.apache.org/batik/faq.html#N10203

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


-- 
WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 


Re: Some current batik observations

Posted by Helder Magalhães <he...@gmail.com>.
Hi Florian Pepping,

> However, the overall situation concerning performance of animations and
> other functions of batik seems to have decreased at the moment.
> We tested the (self-builded) trunk version in our application for a few
> days, but we have
> to step back to the 1.7 version. That's because of many exceptions occur
> (concurrent modification,
> missing fields and some other) and the animations are somewhat
> unaccurate and slow.

It would be great if you could share a few example which would
demonstrate the potential regressions, specially regarding
performance. I recall a couple of changes which could take up a small
additional overhead, but nothing relevant. The concurrent modification
issues is definitely worth a better analysis, specially if you are
already following the thread-safe recommendations [1] and/or have
looked into potential issues within the FAQ [2].


> Perhaps this information may be helpful, otherwise
> just leave it anywhere.

As state, the information will be increasingly helpful as more
details/test cases are provided. Please consider reducing and sharing
a few test cases and/or more details: this may, inclusively, help you
find bugs and/or architecture problems which may be haunting your own
application... ;-)


> Thanks and greetings
>
> Florian Pepping

Cheers,

 Helder Magalhães


[1] http://xmlgraphics.apache.org/batik/using/scripting/java.html#N1002A
[2] http://xmlgraphics.apache.org/batik/faq.html#N10203

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org