diff options
| author | hclam@chromium.org <hclam@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-09-24 21:32:41 +0000 |
|---|---|---|
| committer | hclam@chromium.org <hclam@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-09-24 21:32:41 +0000 |
| commit | a02f64e4b986222548e9cd5bfdcbc940e22e69be (patch) | |
| tree | f9a7782f397ca76456e84228acb691ea5c24968c /cc/cc_tests.gyp | |
| parent | 712c3daa6d226e41ba7888e395249275b77ab1ea (diff) | |
| download | chromium_src-a02f64e4b986222548e9cd5bfdcbc940e22e69be.zip chromium_src-a02f64e4b986222548e9cd5bfdcbc940e22e69be.tar.gz chromium_src-a02f64e4b986222548e9cd5bfdcbc940e22e69be.tar.bz2 | |
Implement asynchronous operation for RWHVP::CopyFromCompositingSurface on Mac
Current implementation blocks the UI thread for a long period of time.
This change uses asynchronous operation to copy the frame buffer.
I have tested this manually with two cases:
1. Thumbnail generation
Tested thumbnails are generated successfully with --force-compositing-mode.
I have also verified that CopyTo() now completes almost instantaneously while
FinishCopy() completes in a relatively short time. Total time that UI thread
is blocked is about 1/4 of previous implementation.
2. Resource destruction
Manually tested that if CompositingIOSurface is destroyed before
asynchronous copy is finished then GL resources associated with the copy
is destroyed.
BUG=145587
Review URL: https://chromiumcodereview.appspot.com/10917307
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@158395 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'cc/cc_tests.gyp')
0 files changed, 0 insertions, 0 deletions