diff options
author | ccameron@chromium.org <ccameron@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-11-16 11:13:15 +0000 |
---|---|---|
committer | ccameron@chromium.org <ccameron@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-11-16 11:13:15 +0000 |
commit | cba3a4bd653a63d4daaa218ceaf3a419024f1c50 (patch) | |
tree | ac20e78fa4dd08aa786c03ea9b908977f4756efb /rlz/chromeos | |
parent | f3631d0eca8b6ca62a7fa272d668cd38b30a4584 (diff) | |
download | chromium_src-cba3a4bd653a63d4daaa218ceaf3a419024f1c50.zip chromium_src-cba3a4bd653a63d4daaa218ceaf3a419024f1c50.tar.gz chromium_src-cba3a4bd653a63d4daaa218ceaf3a419024f1c50.tar.bz2 |
Workaround for IOSurface leak.
Before deleting an IOSurface, we unbind the texture that we attached it to,
and we delete that texture. We also unbind and delete any FBOs that used that
texture. This should remove any internal references to the IOSurface that
still exist, but we were still leaking.
If, in addition to un-binding the texture, we also issue a draw call with the
texture now-unbound from the program it was bound to, the leak goes away. The
narrative that we can fit to this is that the extra draw call is needed to
flush out any remaining references to the IOSurface that the driver had left
hanging around (and that a simple unbind didn't fix).
BUG=158469
Review URL: https://chromiumcodereview.appspot.com/11293269
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168186 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'rlz/chromeos')
0 files changed, 0 insertions, 0 deletions