On Fri, Feb 20, 2015 at 10:50 PM, Christopher Lord <cl...@mozilla.com> wrote:
> 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)). > It's easy to disable async scrolling. It's not so easy to "make everything fast enough (and isolated enough) for pages to do 60fps updates from their main thread". It sounds like you have a specific idea in mind for #3 that's more concrete than what I wrote. I'd like to hear it :-). 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. > If we restrict all Web apps to effects that work on the very lowest-end devices, people won't write Web apps. We need to facilitate graceful degradation, but there must be degradation. 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). > When that's the case, we may need to add one frame of latency so we can overlap compositing frame N with running the UIWorkers for frame N+1. 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. > Unfortunately I don't think it gets you near 90% of what people want to do. For example, it doesn't let you express effects that depend on the direction of scrolling, nor does it help you with any effects that aren't related to scrolling. 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-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
