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 Bastian Wassermann <Ba...@multivac.de> on 2008/11/13 13:53:32 UTC
Issue with handling JSVGCanvas updates asynchronous
I have a problem with updates on my JSvgCanvas.
I am using Batik Version 1.7 in Java 1.4.2, and have an general issue with
the JSvgCanvas updateManager. In my Applikation i handle a Svg-document
with round about 500 Elements. These Elements get Attribute changes (for
example the color or the visibility) by events from java. Every event will
be processed in an invokeLater thread in the updateManager.
There will be about 80 Threads with attribute changes in one second. With
this amount of threads and the threads processed with invokeLater, some
events will be obviously shown delayed, but should show synchronously in
blocks.
Are 80 changes per second to much for batik? Is there a way to combine
these attribute changes to one big update. I have googled and looked up
this issue in this mailing list, but havent found a solution.
---------------------
Multivac Info Box
multivac@multivac.de
---------------------
Multivac
Sepp Haggenmueller GmbH & Co. KG
Bahnhofstrasse 4
D-87787 Wolfertschwenden
Deutschland
Fon: +49(0)8334/601-1181
Fax: +49(0)8334/601-194
Kommanditgesellschaft
Sitz: 87787 Wolfertschwenden
Amtsgericht Memmingen - HRA 8040
Persoenlich haftende Gesellschafterin:
Multivac Sepp Haggenmueller Verwaltungsgesellschaft mbH
Sitz: 87787 Wolfertschwenden
Amtsgericht Memmingen - HRB 10253
Geschaeftsfuehrer: Hans-Joachim Boekstegers (Sprecher), Christian Traumann
http://www.multivac.de
Re: Issue with handling JSVGCanvas updates asynchronous
Posted by "G. Wade Johnson" <gw...@anomaly.org>.
On Thu, 27 Nov 2008 20:53:04 +0000
"Helder Magalhães" <he...@gmail.com> wrote:
> >> As far as I know, this number of changes will be typically more
> >> than feasible for Batik.
>
> > However, 80 changes a second is not impossible for Batik.
>
> Oops, sounds that my writing wasn't very clear (or, at least, not
> clear enough). ;-)
I understood you. I guess I wasn't clear enough in supporting your
statement.<grin/>
> With "more than feasible for Batik" I wasn't meaning it was
> overwhelming for it, on the contrary: my results show that this is
> generally accomplished even more efficiently than other native
> implementations such as modern Web browsers (Firefox, Opera, Webkit).
> Processor usage is kept pretty low and memory consumed is good as
> well, both in absolute values and in comparison to other
> implementations. :-)
As further confirmation, my tests covered Batik, Firefox, and Opera. I
was quite pleasantly surprise by how they all performed. But, in a few
cases, Batik's performance left me stunned.
After I finish this write-up, I plan more tests to push the the edges a
bit more. I'd like to be able to show what kinds of operations have
a negative performance impact and how many operations at a time we can
manage.
G. Wade
--
The man who says he is willing to meet you halfway is usually a poor
judge of distance. -- Laurence J. Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Issue with handling JSVGCanvas updates asynchronous
Posted by Helder Magalhães <he...@gmail.com>.
>> As far as I know, this number of changes will be typically more than
>> feasible for Batik.
> However, 80 changes a second is not impossible for Batik.
Oops, sounds that my writing wasn't very clear (or, at least, not
clear enough). ;-)
With "more than feasible for Batik" I wasn't meaning it was
overwhelming for it, on the contrary: my results show that this is
generally accomplished even more efficiently than other native
implementations such as modern Web browsers (Firefox, Opera, Webkit).
Processor usage is kept pretty low and memory consumed is good as
well, both in absolute values and in comparison to other
implementations. :-)
> G. Wade
Regards,
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: Issue with handling JSVGCanvas updates asynchronous
Posted by "G. Wade Johnson" <gw...@anomaly.org>.
On Thu, 27 Nov 2008 10:09:23 +0000
"Helder Magalhães" <he...@gmail.com> wrote:
> > Are 80 changes per second to much for batik?
>
> As far as I know, this number of changes will be typically more than
> feasible for Batik. Nevertheless, I can imagine it will (tightly)
> depend on the available hardware, complexity of changes and/or canvas
> complexity. Best will always be conducting few tests using a prototype
> application.
>
> Nevertheless, I did some performance research [1] a few months ago,
> although (unfortunately for answering your question) not exclusively
> focused in Batik. Changing a single properly for about 250 objects in
> a canvas I'd consider graphically simple (hundreds of objects but no
> CPU intensive stuff such as animation, gradients, text, etc.) was
> pretty efficient, even compared to other native SVG implementations.
> These manipulations are done through scripting (within the SVG scope),
> so updating from the Java environment should be even quicker. ;-)
I'm currently working on some performance testing of the SVG viewers
that I have available on my platform. Once I finish the writeup I plan
to publish it on my website.
The results have been quite a bit better than expected.
As you say, it very much depends on the complexity of the image and the
changes. However, 80 changes a second is not impossible for Batik.
I'm not really sure that we can perceive changes at that frequency
(isn't video somewhere around 30/sec). If the speed is too much, you
might be able to batch changes and update them at a slightly slower
rate.
G. Wade
--
As a software development model, Anarchy does not scale well.
-- Dave Welch
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Issue with handling JSVGCanvas updates asynchronous
Posted by Helder Magalhães <he...@gmail.com>.
> Are 80 changes per second to much for batik?
As far as I know, this number of changes will be typically more than
feasible for Batik. Nevertheless, I can imagine it will (tightly)
depend on the available hardware, complexity of changes and/or canvas
complexity. Best will always be conducting few tests using a prototype
application.
Nevertheless, I did some performance research [1] a few months ago,
although (unfortunately for answering your question) not exclusively
focused in Batik. Changing a single properly for about 250 objects in
a canvas I'd consider graphically simple (hundreds of objects but no
CPU intensive stuff such as animation, gradients, text, etc.) was
pretty efficient, even compared to other native SVG implementations.
These manipulations are done through scripting (within the SVG scope),
so updating from the Java environment should be even quicker. ;-)
Hope this helps,
Helder Magalhães
[1] http://www.svgopen.org/2008/papers/44-Visualization_and_interaction_with_Synoptics/#d4e265
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org