- From: Dirk Schulze <dschulze@adobe.com>
- Date: Mon, 4 Jun 2012 21:40:14 -0700
- To: Brian Birtles <birtles@gmail.com>
- CC: "public-fx@w3.org" <public-fx@w3.org>
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 >
Received on Tuesday, 5 June 2012 04:40:57 UTC