On Friday, February 20, 2015 at 10:50:12 AM UTC+1, Christopher Lord 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 agree that this could cover a lot for use-cases. You _can_ build the navigation and the core transitions of your app around scrolling. But it implies a fair amount of nested scrollable areas, user initiated scrolling + scrolling APIs calls, snapping etc... So I don't think #1 alone takes us there, not without touch-action and snap points support. > [...] > 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) > [...] Aren't we just going to skip frames while the worker "runs separately from the compositor for a while"? Not sure I fully understand how (from a user-perspective) a UI worker jank would be worse than a main thread jank during an interaction. > 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). Funny, the first advanced use-case that came to my mind for UI workers was re-ordering icons on the gaia homescreen :) There's a bit of everything: we need to drag one icon, transition a screenful of icons to different positions and scroll the container when we're at one of the page's extremity. I think it's a good benchmark. If touch coordinates are provided to UI workers, I believe it could yield a cleaner and faster implementation where we pull all the live-reordering code in the worker and just mutate the DOM on touchend (or after a postMessage from the UI Worker?). But you know this code better than I do, how much of #3 would be required to get it to 60fps? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
