On Thu, Feb 19, 2015 at 10:25 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Fri, Feb 20, 2015 at 4:02 PM, James Long <longs...@gmail.com> wrote: > > Personally I think what we *really* need to be working on is making > all of the DOM APIs asynchronous. That's what Servo needs anyway. > That's a step in the right direction for #3, and we can see much more > we can get out of the main thread after that. > > I don't see how making DOM APIs asynchronous really helps you achieve #3. > There are some specific cases where custom layouts need to repeatedly > measure content, that currently rely on APIs that trigger multiple > sequential synchronous reflows, which would be better served by less > synchronous APIs. We have nebulous plans for addressing that (it's not as > easy as "make everything a Promise"). But those aren't the main problems > mobile Web apps face right now AFAIK.
You may be right, but it just seems pretty awful that you might accidentally stall the JS event loop because you touched the DOM and you didn't expect it to take so long (say, 30ms, dropping a few frames). The Servo team even said they want to look into making them async: https://news.ycombinator.com/item?id=9011767 However, I have no real evidence this will help anything. Eventually I'd love to see the Servo model in real-world browsers where things are running on separate threads. But that's, like, seriously long-term. > On Fri, Feb 20, 2015 at 4:11 PM, James Long <longs...@gmail.com> wrote: >> >> Note however that people in the native app world believe that it's >> very important that whatever applies the animations is run on the same >> thread that handles input. Otherwise it's very easy for animations to >> get out-of-sync. If you swipe a scroll view on iOS, and it has that >> momentum scroll, and you place your finger down it immediately stops >> where it is. I've talked to several engineers that try to do this kind >> of stuff with CSS animations but because they are async, it's not >> nearly as reliable as native. Native platforms fire the touch event, >> and you apply the animation update immediately in the same thread. > > > Thanks, we'll take that into account. If the standards committees are taking a serious look into this, I would really recommend talking to one of the people at Facebook working on React Native. They spent years trying to get this kind of stuff working on the web and React Native is born out of problems they faced with getting 60 FPS. I think they would have tons of good feedback for you, for example like my paragraph above. I'm happy to help someone from that team get involved here if you want. (I'm sure you are well aware of the problems they would tell you, but they have some really good reasons for their solution) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
