It's great to see this being discussed! Personally, I'd like to see all three of these, and I think they have quite particular use-cases. #2 is my least favourite, however, and I'll discuss this below.
I'd like to see #1 implemented first for two reasons; 1- I know this is easy to do given our platform, and I expect the same for other browser vendors, and 2- behaviour here is 100% predictable. There is nothing unexpected that can happen with this method and it's easy to employ. It doesn't require writing any JS, and developers are already used to optimising for the currently async-animatable CSS properties, so we can expect people not to do anything too silly with it. I'd like to see #3 implemented second, again for two reasons; 1- It's, again, reasonably easy to do. You can bypass a lot of machinery already, but making it explicit would make things easier and more obvious for people. I expect that part of this would also involve handling scrolling yourself too (we're on our way to removing the machinery to do synchronous scrolling, and it'd never respond the same way as async, so I think it'd be good to make it explicit). 2- There's a very clear use-case here. Not all web-apps are based around vertically scrolling a complex text layout, which is pretty much what the entire platform is built around. Games could get a nice boost here, as could some more unusual applications (e.g. scientific monitoring apps that mainly just want to draw charts very quickly (thinking specifically of Vernier LabQuest-style applications)). I'd like to see #2 implemented the least, mainly because I think it's the most complex solution, from both the platform and the user side. It's worrying that behaviour is unpredictable - if you have a time budget, the same code on one device can deliver wildly different results on another, and I think this would just introduce inconsistent and unexplainable behaviour (from a user-perspective), and encourage developers to special-case particular devices and do awful user-agent string matching. This is a neat idea, but I just see it breaking more things than it solves, vs. the other two ideas. I'd probably change my mind given a compelling use-case, but I'm struggling to think of anything that couldn't be implemented with a combination of #1 and #3. Also, I realise this is just a throw-away detail, but an 8ms budget would be pretty huge. I doubt we can get our compositing done on mobile if we halve our budget (we can barely get it done as it is). I do strongly think that #1 is the way to go immediately - people have been asking for this for ages (myself included), and it covers just about 90% of what you'd want to do, in a safe, easy-to-use and performant way. Cheers, --Chris On Fri, Feb 20, 2015 at 2:27 AM, Robert O'Callahan <rob...@ocallahan.org> wrote: > Last week in Sydney I spent a lot of time talking to Chrome devs about > different approaches for 60fps effects in Web pages. There are three > different kinds of approaches being discussed (so far): > 1) Apple's animation-timeline proposal, which lets CSS animations use > scroll position as an input instead of time. > 2) UIWorker: some kind of JS worker that receives callbacks during > composition; each callback can take inputs such as time and scroll > position(s) as inputs and can update certain CSS properties (e.g. > transforms, opacity) on elements that the compositor then uses. > 3) Provide a way for pages to turn off async scrolling and make everything > fast enough (and isolated enough) for pages to do 60fps updates from their > main thread. > > All of these approaches have problems. Approach #1 is much more limited in > its expressiveness than the alternatives. Approach #3 is more fragile and > less composable than the alternatives --- sharing your main thread with any > JS you don't control could cause jank. I like #2. It's strictly more > powerful than #1 without the downsides of #3. > > Obvious question: how do we stop UIWorkers janking the compositor? We could > give them a time budget (say 8ms). If a worker blows its budget, we notify > it by sending it an event, we give up on it and composite anyway, and we > run it separately from the compositor for a while. This requires an API > design that lets UIWorkers still work, with some lag, when the compositor > is not blocking on them, but that seems doable. > > Should UIWorkers have access to the full Worker API? It seems like there's > no reason not to give them that. > > How should we explain the CSS effects of UIWorkers? A promising idea is to > extend the Web Animations API to allow adding a new kind of animation > effect to DOM elements --- a UIWorker-controlled effect. Essentially the > UIWorker would then be responsible for computing the output of the timing > function in each frame. The UIWorker could then animate *any* CSS property, > though most property updates would require a round trip through main thread > layout/rendering before they get rendered. > > One good thing about UIWorkers is extensibility. We can imagine providing > touch input coordinates to UIWorkers to enable 60fps object dragging (with > arbitrary effects like resistance, snapping, etc). UIWorkers could render > to canvases: this would let you render VR with minimum latency, and let you > render to canvases used by CSS masking for 60fps dissolves and clipping > effects. If you really want to, you could go all Flipboard and render your > entire UI to a canvas in the compositor --- if you keep hitting your > deadlines. > > I like the idea of doing #2 before either #1 or #3. > > Rob > -- > oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo > owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo > osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo > owohooo > osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o > oioso > oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo > owohooo > osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro > ooofo > otohoeo ofoioroeo ooofo ohoeololo. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
