Mac: Well-behaved accelerated plugins, preparation

This moves IOSurfaces into NSOpenGLViews instead of CALayers.

The advantage of this is that we can use hole-punching (which I'm leaving for a separate CL, but which is easy to add: see diff from patch set 6 to 5), which fixes the appearance of find bar etc. Also, we don't have to hack around coreanimation behavior we don't want, like appkit destroying and recreating our layers, and CA animating everything implicitly.

Even though this CL doesn't have hole punching yet, it fixes the find bar in most cases already, because now only the area actually covered by a plugin is drawn via opengl – so if the findbar doesn't overlap the accelerated plugin, it will be visible.

I didn't test what happens if a page uses both accelerated plugins and the compositor. One view covering the whole tab is created for the compositor, and one view for every plugin. It might even work, but I couldn't find a page to test this with, and accelerated plugins will be handled by the compositor anyway.

The opengl views don't handle any events: Events fall through to the parent view (RWHVMac) and are handled as before.

BUG=51748
TEST=
* Go to youtube, video should still paint correctly (even when scrolling, switching tabs, resizing the window rapidly, etc). Mouse clicks and keyboard events in the player should still work.
* Build with `GYP_DEFINES="use_accelerated_compositing=1" gclient runhooks`, run with --enable-accelerated-compositing. Demos at http://webkit.org/blog/386/3d-transforms/ should still look fine (the color shift is not a regression caused by this CL, it was that way before)

Review URL: http://codereview.chromium.org/3010054

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55663 0039d316-1c4b-4281-b951-d872f2087c98

0 files changed, 0 insertions, 0 deletions