On Wed, Oct 16, 2013 at 8:01 AM, Justin Novosad <ju...@google.com> wrote:
> > ... oh... so the UI could be updated even if JS is blocking... the future > > is bright :-) > > > > If the UI is all painted in a canvas, then yes. > > Let's not get ahead of ourselves though. Browsers that have a compositor in > a separate thread can present frames without synchronizing with the main > thread, but updating a regular (DOM-based) UI would likely require style > and layout calculations to be propagated from the main thread to the > compositor. Right, that's the only sort of async update we're talking about here: changing what gets composited, and not anything that affects layout or is detectable by scripts. But actually, there's no disagreement. I misread Kenneth's mail as saying "your proposal requires synchronization with the main thread", but he actually said "this other proposal requires synchronization with the main thread (but has other benefits)". I'm not sure how big a problem that synchronization will be. Posting messages should be extremely cheap: essentially free, when you're just transferring an object to a thread in the same process. The UI thread should also not be heavily loaded: you shouldn't have to wait long for the script to receive the object and push it into the canvas. But, even a cost of 2ms would be a massive hit, since that's 12% of the time you have available when rendering at 60 FPS. In practice it might make it harder to sustain smooth 60 FPS animation. For example, if the main thread occasionally spends 4ms doing GC work, you may have a rendering hitch that you wouldn't have otherwise. -- Glenn Maynard
