What steps will reproduce the problem?
Using Owlephant, Flash 10, view the attachment baseVal.html with
?svg.render.forceflash=true
What is the expected output?
The color animation sequence of the rectangle should be
0s: red
1s: green
2s: blue
3s: green
4s: red
What do you see instead?
0s: red
2s: blue
3s: red
The animated part of the test case is:
<g fill="red">
<set attributeName="fill" to="green" begin="1s" dur="3"/>
<rect x="100" y="100" width="800" height="600" stroke="none">
<set attributeName="fill" to="blue" begin="2s" dur="1s"/>
</rect>
</g>
When the <set to="blue"/> animation is not active, getAnimAttribute()
determines the baseVal for the attribute and returns that value. I think that
getAnimAttribute should return null - as if there were no animations - and let
getAttribute() determine the appropriate action.
In getAnimAttribute, baseVal is only used as a starting point for additive
animations and as a fallthrough value when there are no effective animations.
This test case would work if the returned baseVal was correct.
To evaluate baseVal, getAttribute is called with applyAnimations=false.
Depending on what the inherit flag is set to (in this case true) the end result
is the non-animated value on the outer <g> element - "red". Possibly a better
approach would be to evaluate the local non-animated value, then if null, and
the inherit flag is true, evaluate the (animated) inherited value. A secondary
problem is that getAttribute is often called with inherit=true even though the
attribute is not listed as inheritable.
Considering that the baseVal evaluation is part of a bigger complexity issue
concerning getAttribute, the attached patch addresses only the strategy of
returning null when there are no effective animations. Which is enough to make
the test case work correctly.
Original issue reported on code.google.com by k...@svgmaker.com on 2 Dec 2010 at 6:57
Original issue reported on code.google.com by
k...@svgmaker.com
on 2 Dec 2010 at 6:57Attachments: