diff options
| author | jbates@chromium.org <jbates@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-06-13 20:07:28 +0000 |
|---|---|---|
| committer | jbates@chromium.org <jbates@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-06-13 20:07:28 +0000 |
| commit | 6bfae22b20d5750a722bfe87332a17c53641104c (patch) | |
| tree | c14fd5efda900c0814b730d35e0a1c3f025760f2 /remoting/host/simple_host_process.cc | |
| parent | 1cabf5eca2cf1e085c8dfcde89bd203a560ae00b (diff) | |
| download | chromium_src-6bfae22b20d5750a722bfe87332a17c53641104c.zip chromium_src-6bfae22b20d5750a722bfe87332a17c53641104c.tar.gz chromium_src-6bfae22b20d5750a722bfe87332a17c53641104c.tar.bz2 | |
Previously, the DisplayLink would never start until a software draw was done at least once. With force-compositing-mode, the software draw was never done, causing tabs to lockup indefinitely waiting for the swap acknowledgement. This fix ensures that the DisplayLink is running immediately.
The Cocoa setUpGState callback was required to avoid "invalid drawable" errors when setView was called on the NSOpenGLContext.
Another deadlock cause could be the GpuChannel route getting removed while the renderer is blocked on a FlushSync. For this, a method has been added to GpuCommandBufferStub to unblock/cleanup that is called from GpuChannel before the IPC route is removed.
Trace events have been added in places that will help debug related issues in the future.
BUG=84343
TEST=launch with --force-compositing-mode; open about:flags; in the same tab, open ycombinator.com and it should not hang.
Review URL: http://codereview.chromium.org/6993043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@88877 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'remoting/host/simple_host_process.cc')
0 files changed, 0 insertions, 0 deletions