summaryrefslogtreecommitdiffstats
path: root/rlz/chromeos
diff options
context:
space:
mode:
authorccameron@chromium.org <ccameron@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2012-11-16 11:13:15 +0000
committerccameron@chromium.org <ccameron@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2012-11-16 11:13:15 +0000
commitcba3a4bd653a63d4daaa218ceaf3a419024f1c50 (patch)
treeac20e78fa4dd08aa786c03ea9b908977f4756efb /rlz/chromeos
parentf3631d0eca8b6ca62a7fa272d668cd38b30a4584 (diff)
downloadchromium_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