Hi Cameron,

Cameron McCormack <[EMAIL PROTECTED]> wrote on 10/26/2006 08:12:55 AM:

> BTW, the regression I mention on that page in the solitaire example I?m
> pretty sure was introduced from the animation support.  If you run it
> and drag a card, the rendering isn?t updated until the mouse is
> released.  It?s either a problem with the RunnableQueue (from when I
> poked about in there) or the SVGAnimatedTransformList implementation.

    I was able to track this down yesterday.  The problem is both
a deep one and a simple one ;) You have switched updating almost entirely
from registering DOM listeners to being notified of animated attributes
be changed (Bridge.handleAnimatedAttributeChanged).  I actually quite
like this it is a move that could make a real dependency tracker more
feasible.  The problem is that currently the sending of the attribute 
change
notifications only happens if an animatable attribute has a 
LiveAttributeValue
(such as SVGOMAnimatedTransformList), if it's live attribute value is
cleared then the attribute ceases to be treated as animated any more.

    So the bug is that the live attribute values are only held by the
SoftDoublyIndexedTable which as it's name implies only holds the value
with a soft reference.  So the bug occurs if the AnimatedTransformList
(the transform attributes live attribute type) get's GCed before the code
starts manipulating the transform on the group.

    This is the deep part.  The bug applies to every animatable attribute!
The shallow bit is that there are I think two fairly simple solutions to
the problem:

        1) Change the SoftDoublyIndexedTable into a 
HardDoublyIndexedTable.

        2) Have the Bridges hold a hard reference to the animatable values
that they use.

    Of the two the second is my preference, this could potentially
speed things up as the get's would no longer need to go through the
HashTable nonsense.  But it raises the issue that essentially all 
attributes would almost always have their live attribute present.
This makes me think of potentially abolishing the separate live attribute
values table and adding a LAV member to the AttrNodes (either all
or just the one's with potential live attributes).

    What do people think?


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to