Re: [css3-transforms] interpolation of transform lists

On Jul 24, 2012, at 4:10 PM, Dirk Schulze 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.
>>> 
>>> 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?
Just as a follow up example:

matrix3d() perspective()
matrix3d() perspective()

Is it right that for these functions every function pair gets interpolated individually? So, every function is transformed to a matrix first and interpolated individually after matrix decomposing? Otherwise implementations would need to look ahead.

Greetings,
Dirk


> 
> Greetings,
> Dirk
> 
> 
>> 
>> Simon
>> 
> 
>

Received on Thursday, 26 July 2012 13:56:55 UTC