On Jun 4, 2012, at 6:03 PM, Brian Birtles wrote:
> (2012/06/05 0:04), Dirk Schulze wrote:
>> I somehow agree. It needs to be defined what the underlying value is,
>> then we can allow to-animation [1]. The problem that I see, is that
>> the underlying value can be animated as well. Therefore the addition
>> on transform functions can cause a performance impact, since in a lot
>> of cases the decomposing of the underlying value must be done on
>> every animation step.
>
> That's the case for a lot of other types too. This doesn't make things
> any harder.
>
>>> Minor problem one has to face (as an author) with this: If a lower
>>> priority animation is ended before the end of the to-animation,
>>> and fill of this is not freeze, a new underlying value may appear,
>>> that has another type. In this situation of course the viewer has
>>> to reconsider, whether rule 1 or 2 has to be used. But typically
>>> this is not really a big additional problem, because typically this
>>> end without freeze will result anyway in a discontinuity and the
>>> author will not get a smooth change anyway.
>> But might be for the implementation; performance wise. W might need
>> feedback of implementers here. It makes no sense to allow
>> to-animations when no one can use them.
>
> I don't see any problem here from an implementation point of view.
It makes hardware accelerating SVG transforms even harder IMO. But I don't have a problem with defining it in general.
Dirk
>
> Best regards,
>
> Brian Birtles
>