Title: [114385] trunk/Source/WebKit/gtk
Revision
114385
Author
[email protected]
Date
2012-04-17 09:12:25 -0700 (Tue, 17 Apr 2012)

Log Message

[GTK] Enable back double buffering on WebKitWebView to fix flickering
https://bugs.webkit.org/show_bug.cgi?id=84149

Patch by Carlos Garnacho <[email protected]> on 2012-04-17
Reviewed by Martin Robinson.

Despite having WebKitWebView its own backing buffer, calling
gtk_widget_set_double_buffered(...,FALSE) may still pose side
effects, such as ensuring that all drawing operations are
flushed to the X server before rendering a non-double buffered
widget, which may translate into flickering of the parent
GdkWindow before the WebKitWebView itself is rendered.

Enabling back double buffering solves this as all contents are
first composited together before getting to the front buffer,
but effectively acts as 3rd buffer. This is sort of unavoidable
unless GTK+ gains a "let me take ownership of the backing buffer
for this widget", which currently lacks.

* webkit/webkitwebview.cpp:
(webkit_web_view_init): Remove call to gtk_widget_set_double_buffered(..., FALSE)

Modified Paths

Diff

Modified: trunk/Source/WebKit/gtk/ChangeLog (114384 => 114385)


--- trunk/Source/WebKit/gtk/ChangeLog	2012-04-17 16:10:38 UTC (rev 114384)
+++ trunk/Source/WebKit/gtk/ChangeLog	2012-04-17 16:12:25 UTC (rev 114385)
@@ -1,3 +1,26 @@
+2012-04-17  Carlos Garnacho  <[email protected]>
+
+        [GTK] Enable back double buffering on WebKitWebView to fix flickering
+        https://bugs.webkit.org/show_bug.cgi?id=84149
+
+        Reviewed by Martin Robinson.
+
+        Despite having WebKitWebView its own backing buffer, calling
+        gtk_widget_set_double_buffered(...,FALSE) may still pose side
+        effects, such as ensuring that all drawing operations are 
+        flushed to the X server before rendering a non-double buffered
+        widget, which may translate into flickering of the parent 
+        GdkWindow before the WebKitWebView itself is rendered. 
+
+        Enabling back double buffering solves this as all contents are 
+        first composited together before getting to the front buffer,
+        but effectively acts as 3rd buffer. This is sort of unavoidable
+        unless GTK+ gains a "let me take ownership of the backing buffer
+        for this widget", which currently lacks.
+
+        * webkit/webkitwebview.cpp:
+        (webkit_web_view_init): Remove call to gtk_widget_set_double_buffered(..., FALSE)
+
 2012-04-06  Martin Robinson  <[email protected]>
 
         [GTK] Accelerated compositing is broken after recent TextureMapper reorganizations

Modified: trunk/Source/WebKit/gtk/webkit/webkitwebview.cpp (114384 => 114385)


--- trunk/Source/WebKit/gtk/webkit/webkitwebview.cpp	2012-04-17 16:10:38 UTC (rev 114384)
+++ trunk/Source/WebKit/gtk/webkit/webkitwebview.cpp	2012-04-17 16:12:25 UTC (rev 114385)
@@ -3622,7 +3622,6 @@
     priv->viewportAttributes->priv->webView = webView;
 
     gtk_widget_set_can_focus(GTK_WIDGET(webView), TRUE);
-    gtk_widget_set_double_buffered(GTK_WIDGET(webView), FALSE);
 
     priv->mainFrame = WEBKIT_WEB_FRAME(webkit_web_frame_new(webView));
     priv->lastPopupXPosition = priv->lastPopupYPosition = -1;
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes

Reply via email to