|
|
Created:
6 years, 7 months ago by danakj Modified:
6 years, 6 months ago Reviewers:
enne (OOO) CC:
chromium-reviews, cc-bugs_chromium.org, boliu, brianderson, vmpstr Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
Descriptioncc: Stop blocking the main thread in CreateAndInitializeOutputSurface.
The ThreadProxy does not need to block the main thread anymore, instead
have it post back DidInitializeOutputSurface() with the result of the
process.
We would delete all contents textures on the compositor thread during
OutputSurface creation, which doesn't really make sense, cuz the
ResourceProvider won't be the same one anymore, and this required
blocking the thread.
We also notified the main thread that the OutputSurface was lost when
creating the new output surface.
Instead, post a DidLoseOutputSurface() to the main thread to inform
the LayerTreeHost right away, and have that block and clean up
the contents textures immediately (to be removed when we always do
impl-side painting).
R=enne
BUG=374287
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=272276
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=276921
Patch Set 1 #Patch Set 2 : threadproxy-nonblock-create: . #Patch Set 3 : threadproxy-nonblock-create: . #
Total comments: 4
Patch Set 4 : threadproxy-nonblock-create: . #Patch Set 5 : threadproxy-nonblock-create: rebase #Patch Set 6 : threadproxy-nonblock-create: defer #
Messages
Total messages: 51 (0 generated)
Depends on https://codereview.chromium.org/286293002/
https://codereview.chromium.org/287193003/diff/60001/cc/trees/thread_proxy.cc File cc/trees/thread_proxy.cc (right): https://codereview.chromium.org/287193003/diff/60001/cc/trees/thread_proxy.cc... cc/trees/thread_proxy.cc:248: base::Bind(&ThreadProxy::CreateAndInitializeOutputSurface, How is this not an infinite loop during failure? CreateAndInitializeOutputSurface -> CreateOutputSurface returns NULL -> DidInitializeOutputSurface(false, ...) -> PostTask(...CreateAndInitializeOutputSurface...)
https://codereview.chromium.org/287193003/diff/60001/cc/trees/thread_proxy.cc File cc/trees/thread_proxy.cc (right): https://codereview.chromium.org/287193003/diff/60001/cc/trees/thread_proxy.cc... cc/trees/thread_proxy.cc:248: base::Bind(&ThreadProxy::CreateAndInitializeOutputSurface, On 2014/05/16 22:37:29, enne wrote: > How is this not an infinite loop during failure? > > CreateAndInitializeOutputSurface -> CreateOutputSurface returns NULL -> > DidInitializeOutputSurface(false, ...) -> > PostTask(...CreateAndInitializeOutputSurface...) After 5 failures, LayerTreeHost will LOG(FATAL) in OnCreateAndInitializeOutputSurfaceAttempted.
https://codereview.chromium.org/287193003/diff/60001/cc/trees/thread_proxy.cc File cc/trees/thread_proxy.cc (right): https://codereview.chromium.org/287193003/diff/60001/cc/trees/thread_proxy.cc... cc/trees/thread_proxy.cc:248: base::Bind(&ThreadProxy::CreateAndInitializeOutputSurface, On 2014/05/16 22:45:29, danakj wrote: > On 2014/05/16 22:37:29, enne wrote: > > How is this not an infinite loop during failure? > > > > CreateAndInitializeOutputSurface -> CreateOutputSurface returns NULL -> > > DidInitializeOutputSurface(false, ...) -> > > PostTask(...CreateAndInitializeOutputSurface...) > > After 5 failures, LayerTreeHost will LOG(FATAL) in > OnCreateAndInitializeOutputSurfaceAttempted. And this will just keep posting tasks?
https://codereview.chromium.org/287193003/diff/60001/cc/trees/thread_proxy.cc File cc/trees/thread_proxy.cc (right): https://codereview.chromium.org/287193003/diff/60001/cc/trees/thread_proxy.cc... cc/trees/thread_proxy.cc:248: base::Bind(&ThreadProxy::CreateAndInitializeOutputSurface, On 2014/05/16 22:46:31, enne wrote: > On 2014/05/16 22:45:29, danakj wrote: > > On 2014/05/16 22:37:29, enne wrote: > > > How is this not an infinite loop during failure? > > > > > > CreateAndInitializeOutputSurface -> CreateOutputSurface returns NULL -> > > > DidInitializeOutputSurface(false, ...) -> > > > PostTask(...CreateAndInitializeOutputSurface...) > > > > After 5 failures, LayerTreeHost will LOG(FATAL) in > > OnCreateAndInitializeOutputSurfaceAttempted. > > And this will just keep posting tasks? This calls OnCreateAndInitializeOutputSurfaceAttempted on line 243. The LOG(FATAL) would crash so we'd stop. This should match our current behaviour also, minus allowing the OutputSurface to be initailized mid-initialization by CompositeAndReadback, at least this was my intent here.
Ok. I think I've wrapped my head around this. lgtm
The CQ bit was checked by danakj@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/danakj@chromium.org/287193003/60001
FYI, CQ is re-trying this CL (attempt #1). Please consider checking whether the failures are real, and report flakes to chrome-troopers@google.com. The failing builders are: android_dbg_triggered_tests on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...) mac_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
The CQ bit was checked by danakj@chromium.org
The CQ bit was unchecked by danakj@chromium.org
The CQ bit was checked by danakj@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/danakj@chromium.org/287193003/60001
FYI, CQ is re-trying this CL (attempt #1). Please consider checking whether the failures are real, and report flakes to chrome-troopers@google.com. The failing builders are: mac_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
The CQ bit was checked by danakj@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/danakj@chromium.org/287193003/60001
FYI, CQ is re-trying this CL (attempt #1). Please consider checking whether the failures are real, and report flakes to chrome-troopers@google.com. The failing builders are: mac_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
The CQ bit was unchecked by danakj@chromium.org
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
The CQ bit was checked by danakj@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/danakj@chromium.org/287193003/80001
Message was sent while issue was closed.
Change committed as 272276
Message was sent while issue was closed.
A revert of this CL has been created in https://codereview.chromium.org/299233002/ by danakj@chromium.org. The reason for reverting is: This may be causing mac browser test flakiness: https://code.google.com/p/chromium/issues/detail?id=376649 .
I've fixed this CL to not blow up and try to do a BeginMainFrame when the output surface is lost. I'm not sure if that resolves the resource_provider invalid resource CHECK that was also occuring or not. I'm going to run some mac try bots and see what they do.
Green trybots, going to try another run too. But please take a look at the changes in the last patchset.
On 2014/06/11 at 17:05:28, danakj wrote: > Green trybots, going to try another run too. But please take a look at the changes in the last patchset. Seems legit. lgtm
I ran the DownloadExtensionTest.DownloadExtensionTest_Download_ConflictAction a bunch of times on mac and it didnt fail there for me locally, so going to reland.
The CQ bit was checked by danakj@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/danakj@chromium.org/287193003/120001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was checked by danakj@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/danakj@chromium.org/287193003/120001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was checked by danakj@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/danakj@chromium.org/287193003/120001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was checked by danakj@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/danakj@chromium.org/287193003/120001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
Message was sent while issue was closed.
Change committed as 276921 |