Bug 92368 - [META][GTK][WK2] Enable UI_SIDE_COMPOSITING for WebKit2 GTK
Summary: [META][GTK][WK2] Enable UI_SIDE_COMPOSITING for WebKit2 GTK
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-26 05:04 PDT by Gwang Yoon Hwang
Modified: 2012-10-25 00:29 PDT (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gwang Yoon Hwang 2012-07-26 05:04:44 PDT
This is a metabug to track UI_SIDE_COMPOSITING support in WebKit2 GTK port.

QT port has already implemented this feature but unfortunately GTK port hasn't.
So, we are working to support UI_SIDE_COMPOSITING in WebKit2 GTK.

But, we need to consider the following issues.

1. UI_SIDE_COMPOSITING depends on TILED_BACKING_STORE. But GTK does not use TILED_BACKING_STORE.
    - It is hard to reuse other ports' code because of WidgetBackingStoreCairo.
    - Is TiledBackingStoreCairo far slower than WidgetBackingStoreCairo? Do we need to maintain WidgetBackingStoreCairo?

2. Current GTK port supports CLUTTER, but I do not know the current status about clutter in WebKit2.
    - Is there any activity about clutter in WebKit2? It seems a little bit hard to support clutter at same time.
    - I need some hands :)

I want comments/discussions about these issues.

My current plan to land UI_SIDE_COMPOSITING on WebKit2 Gtk:
1. Enable the "tiled backing store"
2. Enable the "ui side compositing"
Comment 1 Martin Robinson 2012-07-26 06:22:22 PDT
I'm not sure UI_SIDE_COMPOSITING is something that we want in GTK+ at the moment. We haven't established if it's necessary yet. Perhaps it would be good to discuss this issue on the WebKitGTK+ list.
Comment 2 Joone Hur 2012-07-26 11:58:34 PDT
> 2. Current GTK port supports CLUTTER, but I do not know the current status about clutter in WebKit2.
>     - Is there any activity about clutter in WebKit2? It seems a little bit hard to support clutter at same time.
>     - I need some hands :)

Currently, I am trying to land AC clutter backend patches for WK1.
https://bugs.webkit.org/show_bug.cgi?id=73767

However, there is no plan of supporting WK2. When WK2 is introduced in webkit-clutter, I will take a look at the possibility of supporting those things.
Comment 3 Kwang Yul Seo 2012-07-27 02:22:50 PDT
(In reply to comment #1)
> I'm not sure UI_SIDE_COMPOSITING is something that we want in GTK+ at the moment. We haven't established if it's necessary yet. Perhaps it would be good to discuss this issue on the WebKitGTK+ list.

Gwang Yoon wiil send an email to webkit-gtk mailing list. 

Can you explain why you think that GTK is not ready for UI_SIDE_COMPOSITING? Efl guys have already refactored Qt's UI_SIDE_COMPOSITING code into reusable form, so Gtk port can simply reuse it.
Comment 4 Martin Robinson 2012-07-27 02:33:09 PDT
(In reply to comment #3)
> > I'm not sure UI_SIDE_COMPOSITING is something that we want in GTK+ at the moment. We haven't established if it's necessary yet. Perhaps it would be good to discuss this issue on the WebKitGTK+ list.

> Can you explain why you think that GTK is not ready for UI_SIDE_COMPOSITING? Efl guys have already refactored Qt's UI_SIDE_COMPOSITING code into reusable form, so Gtk port can simply reuse it.

The thing that's missing from this bug is the answer to the question "Why?" From my discussions with the Qt folks, I concluded that UI-side compositing was the solution to actual problems that they were facing. What is the goal for implementing this for GTK+ especially since we do not yet have full support for touch events? Wouldn't it be better to wait until we know this will solve actual problems? I think it's important to consider these questions, since UI-side compositing *greatly* increases the complexity of the code. Thus in my opinion, it's not appropriate to implement it for the sake of an educational exercise or simply because other ports do.
Comment 5 Kwang Yul Seo 2012-07-27 02:50:16 PDT
(In reply to comment #4)
> The thing that's missing from this bug is the answer to the question "Why?" From my discussions with the Qt folks, I concluded that UI-side compositing was the solution to actual problems that they were facing. What is the goal for implementing this for GTK+ especially since we do not yet have full support for touch events? Wouldn't it be better to wait until we know this will solve actual problems? I think it's important to consider these questions, since UI-side compositing *greatly* increases the complexity of the code. Thus in my opinion, it's not appropriate to implement it for the sake of an educational exercise or simply because other ports do.

Okay. I see your point. I heard that Gwang Yoon has been struggling with real problems with the current implementation of Gtk AC. He will explain more on this.

Also let's listen to YoungTaeck's opinion. He is the guy who ported UI_SIDE_COMPOSITING to Efl port. Because Gtk and Efl share much in common, the reason why he decided to port UI_SIDE_COMPOSITING would probably apply to Gtk port as well.
Comment 6 Gwang Yoon Hwang 2012-07-27 03:08:41 PDT
(In reply to comment #4)
> The thing that's missing from this bug is the answer to the question "Why?" From my discussions with the Qt folks, I concluded that UI-side compositing was the solution to actual problems that they were facing. What is the goal for implementing this for GTK+ especially since we do not yet have full support for touch events? Wouldn't it be better to wait until we know this will solve actual problems? I think it's important to consider these questions, since UI-side compositing *greatly* increases the complexity of the code. Thus in my opinion, it's not appropriate to implement it for the sake of an educational exercise or simply because other ports do.

There are two reasons why we should implement UI_SIDE_COMPOSITING.
1. We are facing on the problem "Xlib: unexpected async reply" on specific embedded system. Because WebProcess and UIProcess have "thread unsafe Xlib connection" at the same time, we need to maintain single Xlib connection.

2. In the embedded system, it is important to reduce workload of the main thread/process.


Anyway, I will send an email to start discussion on webkit-gtk mailing list.
Comment 7 Dongseong Hwang 2012-07-27 03:18:32 PDT
(In reply to comment #6)
> (In reply to comment #4)
> > The thing that's missing from this bug is the answer to the question "Why?" From my discussions with the Qt folks, I concluded that UI-side compositing was the solution to actual problems that they were facing. What is the goal for implementing this for GTK+ especially since we do not yet have full support for touch events? Wouldn't it be better to wait until we know this will solve actual problems? I think it's important to consider these questions, since UI-side compositing *greatly* increases the complexity of the code. Thus in my opinion, it's not appropriate to implement it for the sake of an educational exercise or simply because other ports do.
> 
> There are two reasons why we should implement UI_SIDE_COMPOSITING.
> 1. We are facing on the problem "Xlib: unexpected async reply" on specific embedded system. Because WebProcess and UIProcess have "thread unsafe Xlib connection" at the same time, we need to maintain single Xlib connection.
> 
> 2. In the embedded system, it is important to reduce workload of the main thread/process.
> 
> 
> Anyway, I will send an email to start discussion on webkit-gtk mailing list.

I agree on Gwang Yoon's reasons, especially #2.

Only AC from GTK WebKit2 runs on the main thread.
Mac uses CA that has its own thread.
Chrome guys implemented Chrome Compositor that runs on the impl thread.
Qt and EFL uses UI_SIDE_COMPOSITING.

I think there is an agreement on running AC off the main thread, in order to increase scrolling performance.
So, GTK should also implement AC off of the main thread, UI_SIDE_COMPOSITING already exists which can be reused.
IMHO, this change does not increase the complexity because it will just reuse the existing implementation.

GTK, Qt and EFL guys can focus on improving UI_SIDE_COMPOSITING.
Comment 8 Gwang Yoon Hwang 2012-10-25 00:29:51 PDT
We filed a new bug for threaded compositor in webkit GTK+.
See https://bugs.webkit.org/show_bug.cgi?id=100341