[Webkit-unassigned] [Bug 95358] [Chromium] CCLayerTreeHostTestScrollChildLayer makes the wrong assumptions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=95358





--- Comment #10 from James Robinson <jamesr at chromium.org>  2012-08-30 09:55:49 PST ---
(In reply to comment #7)
> Ok, I understand now. Thanks for reverting that change, and sorry for breaking this and not paying attention to Nat's comment on bug 94721.
> 
> (In reply to comment #5)
> > Sorry, I still don't follow.  Could you walk me through the scenario where we complete 2 commits during one vsync period?
> 
> This is the sequence I was seeing:
> 
> 1. beginFrameComplete
> 2. scheduleUpdateMoreResource
> 3. enter vsync
>  (nothing to draw as still updating resources)
> 4. leave vsync
> 5. updateResourcesComplete
> 6. commit
> 7. scheduleBeginFrame
> 8. beginFrameComplete
> 9. scheduleUpdateMoreResource
> 10. updateResourcesComplete
> 12. commit
> 13. enter vsync
> 14. draw
> 15. leave vsync
> 
> If I understand this correctly we need to delay "7. scheduleBeginFrame" until after "14. draw", right?

Yes, exactly.  After a commit completes we need to go into COMMIT_STATE_WAITING_FOR_FIRST_DRAW and stay there until we draw or are informed that we can't draw at all for some reason (not visible, for instance) and just skip ahead.

If you think about what's going on this makes perfect sense - we've already done a lot of work to get a new frame ready on the main thread and on the impl thread and we need to make sure the user actually sees what happened.  Imagine a WebGL game that in the animate call on the main thread queues up 10ms of GPU work every time.  The scheduler needs to make sure that we run that (via beginFrame) and draw exactly one time each every frame.  If we double up beginFrames, we'll drop a frame.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.