Re: [css3-transforms] interpolation of transform lists

On 25/07/2012, at 9:10 AM, Dirk Schulze <dschulze@adobe.com> wrote:

> 
> On Jul 24, 2012, at 8:55 AM, Simon Fraser wrote:
> 
>> 
>> On Jul 23, 2012, at 3:21 pm, L. David Baron <dbaron@dbaron.org> wrote:
>> 
>>> On Monday 2012-07-23 09:22 -0700, Chris Marrin wrote:
>>>> 
>>>> On Jul 19, 2012, at 5:51 PM, L. David Baron <dbaron@dbaron.org> wrote:
>>>> 
>>>>> On Thursday 2012-07-19 16:54 -0700, Dirk Schulze wrote:
>>>>>> Do I understand your point correctly, that you just want the
>>>>>> affected transformation functions to get interpolated as matrices?
>>>>> 
>>>>> Yes, rather than forcing the entire list to be interpolated as a
>>>>> single matrix.
>>>> 
>>>> You're complicating the rules by doing this. If I have:
>>>> 
>>>> rotate(...) scale(...) translate(...)
>>>> scale(...) rotate(...) translate(...)
>>>> 
>>>> Do you do two separate matrix animations? Taking that to its
>>>> logical conclusion, you could end up doing a dozen expensive
>>>> matrix animations for a long list of unmatched primitives.
>>> 
>>> I'm fine with doing that as a single matrix animation.
>>> 
>>> The "affected transformation functions" in the most deeply quoted
>>> text was referring to perspective(), rotate3d(), matrix(), and
>>> matrix3d().  What I don't like is the idea that interpolating
>>> between:
>>> transform: perspective(5px) skewY(0deg)
>>> and:
>>> transform: perspective(5px) skewY(30deg)
>>> should do a matrix interpolation for the entire list because the
>>> perspective function is defined by the current spec as not having a
>>> corresponding primitive.  (This was not a problem in earlier
>>> drafts.)  I'd like to stick to the principle established in the
>>> earlier draft that if the lists match, they're interpolated
>>> item-by-item.  It seems confusing for authors to do that most of the
>>> time but not all of the time.

This is what WebKit currently implements. I do not see any reason to make it more restrictive than that. If the two lists match item for item, then interpolate between each item separately. This includes perspective().

I think the only thing we need to decide now is whether or not we should allow translateX() to match against translate(), and so on. Currently WebKit does not support this.

Maybe rotate3d() <-> rotateX/Y/Z is controversial. I don't know.

Dean


>>> 
>>> To be clear, though, to restate my response to the most deeply
>>> quoted text above:  I don't particularly care whether they're
>>> interpolated as matrices or interpolated some other way (esp. for
>>> perspective() and maybe for rotate3d()).
>> 
>> I think the text in the draft has drifted away from the original intent,
>> and we're really all in agreement.
>> 
>> Dirk, why can't we treat perspective() and rotated3d() as primitives?
> The spec says currently that primitives are interpolated numerically, which is clearly not the case for perspective and matrix/matrix3d. I am fine with special casing these functions, or finding a different wording.
> 
> My understanding of David's suggestion was different. And sadly I didn't get his clarification in my mail.
> 
> If we special case perspective and matrix/matrix3d, what else should be interpolated as matrix independent of the other function pairs? When do we decide to interpolate the whole lists as one matrix pair, when do we still use per function pair interpolation?
> 
> Greetings,
> Dirk
> 
> 
>> 
>> Simon
>> 
> 
>

Received on Thursday, 26 July 2012 23:02:51 UTC