W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2012

Re: [css3-transforms] ... to-animation

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>
Message-ID: <8B81BA5A-2C00-49E8-987D-05319F13E2BB@adobe.com>

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.


> Best regards,
> Brian Birtles
Received on Tuesday, 5 June 2012 04:40:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:40 UTC