[Webkit-unassigned] [Bug 140494] New: REGRESSION(r177075): [GTK] Creating a second web view disables accelerated compositing in existing web view

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=140494

            Bug ID: 140494
           Summary: REGRESSION(r177075): [GTK] Creating a second web view
                    disables accelerated compositing in existing web view
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Keywords: Gtk, Regression
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cgarcia at igalia.com
                CC: j.isorce at samsung.com, mrobinson at webkit.org,
                    yoon at igalia.com, zan at falconsigh.net

This is very easy to reproduce with epiphany. 

1.- Open ephy and load a page with an AC animation (like poster circle)
2.- Create a new tab
3.- Go back to previous tab

The animation no longer works because AC has been disabled.

The problem is that r177075 moved the creation of the redirected XComposite window to realize method, but leaving the call to webkitWebViewBaseUpdatePreferences() in both places Realize() and CreateWebPage(). webkitWebViewBaseUpdatePreferences() only updates the accelerating compositing setting nowadays, depending on whether the redirected XComposited window could be created or not (something that depends on whether XRender, XComposite and XDamage extensions are available in the current display). So, when the first web view is created, webkitWebViewBaseUpdatePreferences() is called first from CreateWebPage(), and always disabling accelerated compositing because the redirected window hasn't been created yet, and then from Realize() right after the redirected window is created so that accelerated compositing is enabled. When the second web view is created the same happens, but since settings are shared among web views, the first call to webkitWebViewBaseUpdatePreferences() from CreateW

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150115/b7b216da/attachment-0002.html>