- From: Shane Stephens <shans@google.com>
- Date: Mon, 15 Aug 2011 18:26:07 -0700
- To: Brian Manthos <brianman@microsoft.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
- Message-ID: <CAGTfzwTeJ9-+xef3GiZmg-hxv4651FkwHQk-JDOyp4fjvP_1WA@mail.gmail.com>
On Fri, Aug 12, 2011 at 1:01 PM, Brian Manthos <brianman@microsoft.com>wrote: > “resolving sizes down to pixel values before interpolation“**** > > We’re missing each other apparently.**** > > ** ** > > Resolve **nothing** before you have all the necessary data to do so.**** > > ** > Ah, I apologize. I thought you were suggesting that the right gradient representation for interpolation was percentages for stops and pixel values for position and gradient size. Coming back to the original topic, the WebKit animation pipeline currently interpolates at apply time. As we've discussed it's still possible to make gradient interpolation work correctly with this scheme, although as you've pointed out it is more complicated than just interpolating further down the stack. Unfortunately, making big changes to the pipeline is not something I'm likely to be able to do, and it is anyway something I'm wary about - I don't know the context around why the pipeline is the way it is. As an implementation detail, it's easier to interpolate stops at the point where WebKit does it if rules (2) and (3) of color-stop fixup are swapped. It seems that: * swapping these steps merely exchanges one constraint bias for another - i.e. one approach is not more correct than the other * if you are already interpolating lower down the stack, either approach is of similar complexity * only poorly specified gradients (i.e. with mixed pixel and percentage values or clear order inversions) are impacted With this in mind, do you have objections to swapping the two steps? Cheers, -Shane
Received on Tuesday, 16 August 2011 01:26:37 UTC