xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject RE: Dynamic Styling
Date Thu, 21 Sep 2006 09:54:45 GMT
Hi Greg,

"Greg Steele" <gsteele@apt-cafm.com> wrote on 09/20/2006 01:39:39 PM:

> I stumpled into this, but if I group each of the elements, updating
> thousands of elements' class attributes happens almost immediately.

   Just as an FYI the issue is CSS rules.  When you change something
that may impact the CSS cascade we need to invalidate the CSS properties
on that element, all of it's children and it's following siblings,
so that we can re-evalulate any CSS matching rules.

   In this case (since we don't let the DOM drift) this causes an
O(N^2) behavior (you update all 10,000 elements, for each element it
recalculates the CSS cascade for the following elements, or 10,000
element then 9,999 elements, then 9,998, ...)

> There may be some reasonable explanation for this behavior, but it seems
> like a bug to me. 

   An ideal implementation would either simply mark the elements
cascade as dirty and delay recalculation until someone needs it,
or else note that no one depends on this element and avoid the
recascade.  Unfortunately Batik's implementation is not ideal here,
if this a bug or not is largely a matter of perspective ;)

> I would prefer not having to group each shape as this
> will significantly add to my file size, and I don't need the grouping, 
> from this issue.  Thanks for the help!

   The O(n^2) behavior isn't bad unless N is large so splitting your
10000 elements into groups of 10 or 20 would net you almost all of the
savings and reduce the 'g' overhead significantly. You could also
insert the 'g' elements with script once the document is loaded.

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

View raw message