Revert 61561 - Create an X window overlay with static ID for GL contexts.

Reverting due to Valgrind issues on Linux tests:

http://build.chromium.org/buildbot/memory/builders/Linux%20Tests%20(valgrind)(2)/builds/7671/steps/memory%20test:%20ui/logs/stdio

Suppression (error hash=#000000007803F359#):
{
   <insert_a_suppression_name_here>
   Memcheck:Addr4
   fun:_ZN20GtkNativeViewManager9OnDestroyEP10_GtkWidget
   fun:_ZN62_GLOBAL__N_gfx_gtk_native_view_id_manager.cc_00000000_E72B30A69OnDestroyEP10_GtkObjectPv
   fun:g_cclosure_marshal_VOID__VOID
   fun:g_closure_invoke
   fun:signal_emit_unlocked_R
   fun:g_signal_emit_valist
   fun:g_signal_emit
   fun:gtk_object_dispose
   fun:gtk_widget_dispose
   fun:g_object_run_dispose
   fun:gtk_object_destroy
   fun:_ZN23RenderWidgetHostViewGtk7DestroyEv
   fun:_ZN16RenderWidgetHost7DestroyEv
   fun:_ZN16RenderWidgetHost8ShutdownEv
   fun:_ZN14RenderViewHost8ShutdownEv
   fun:_ZN21RenderViewHostManagerD1Ev
   fun:_ZN11TabContentsD0Ev
   fun:_ZN13TabStripModel16InternalCloseTabEP11TabContentsib
   fun:_ZN13TabStripModel17InternalCloseTabsERKSt6vectorIiSaIiEEj
   fun:_ZN13TabStripModel18CloseTabContentsAtEij
   fun:_ZN7Browser13CloseContentsEP11TabContents
   fun:_ZN11TabContents5CloseEP14RenderViewHost
}

No absolute smoking gun.  But seems very likely.

--

This code creates an X window that overlays where tab contents are drawn. The handle associated with this window never changes (unlike the X window associated with a GTK widget that is created and destroyed whenever the widget is realized and unrealized respectively).  This is helpful when creating a GL context associated with an X window. Also, having a floating overlay allows us to handle detaching GPU accelerated tabs.

This code seems to have uncovered a race condition within the GPU process. When a tab that uses accelerated compositing is detached (e.g. http://webkit.org/blog/386/3d-transforms/), the tab contents often don't get displayed even though the tab is redrawn.  A slight delay of about 100ms in the GPU process on the call to glXSwapBuffers (in gl_context_linux.cc) fixes this. To witness that GL can draw to the overlay after delay, try it with a tab with constant animation (e.g. http://webkit.org/blog-files/3d-transforms/poster-circle.html).

I've written a bare bones test (about 150 lines of C) of the overlay technique, and it requires no such delay b/w reparenting the glXSwapBuffers. I've also confirmed that there is no synchronization issues w.r.t. the X server between my patch and GL draw commands. I propose filing a new bug for the race, if this patch gets accepted.

BUG=53345,56419
TEST=Open two tabs, one with GPU rendered content (http://webkit.org/blog/386/3d-transforms/). Detach the tab with GPU rendered content.  GPU process shouldn't crash.

Review URL: http://codereview.chromium.org/3509004
Patch from Jonathan Backer <backer@google.com>.

TBR=piman@chromium.org
Review URL: http://codereview.chromium.org/3548015

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

0 files changed, 0 insertions, 0 deletions