Bug 104521 – [GTK][EFL][WK2] Sharing more web process code between the GTK+ and EFL ports

• Component: WebKit EFL
• Status: RESOLVED WONTFIX

[Joone Hur]

There was an idea about this in the WebKitGtk+ hackfest 2012.
It seems to be reasonable because two ports share a lot of things such as Cairo, GStreamer, Glib, TextureMapper,and etc.
Of course, there are also many different things such as Accelerated Compositing(AC happens in the UI process(EFL) and Web process(GTK+)), RenderTheme and etc.
But, we can push those things into the UI Process if possible.

I'd like to hear your opinion on this idea if it is really feasible.

[Kenneth Rohde Christiansen]

I don't think that is feasible for various reasons.

1) Little gain, beyond our current code sharing which we should promote
2) We need the ability to made changes and this might hinter it
3) We might rewrite the Curl backend (using the right curl_multi interface) and use that
4) We surely have EFL dependencies in WebCore
5) Different target (I think). It seems like GTK+ wants to make a great traditional desktop browser. We on the other hand, have a clear target of making a great modern mobile browser, which can/does mean sacrificing features currently found in desktop browsers. It is also the reason we do compositing in the UI process as earlier experiments did it on the web process side, but the extra XComposite call killed performance.
6) ... 

I am all for cooperation more, but I think this is an unrealistic goal which doesn't bring us much.

For RenderTheme I think we kind of want to go the Chrome way and not integrate with desktop widgets but instead use some nice looking web like widgets which look great on all plaforms. But we need to consider the sizes on mobile devices or do another theme for mobile browsers. This we could do together.

[Martin Robinson]

I don't think it's possible to share the web process itself between two ports. Meanwhile, the benefit of having one binary for two ports is pretty small considering that (at least for GTK+) it just links against a shared library.

Joone, when we talked yesterday I thought we were talking about sharing more of the code between the two ports, such as the main method of the web process.

[Joone Hur]

(In reply to comment #2)
> I don't think it's possible to share the web process itself between two ports. Meanwhile, the benefit of having one binary for two ports is pretty small considering that (at least for GTK+) it just links against a shared library.
> 
> Joone, when we talked yesterday I thought we were talking about sharing more of the code between the two ports, such as the main method of the web process.

Yes, I also mean that this bug is about sharing the code not sharing the web process. I will change the bug title.

[Alejandro Piñeiro]

(In reply to comment #0)
> There was an idea about this in the WebKitGtk+ hackfest 2012.
> It seems to be reasonable because two ports share a lot of things such as Cairo, GStreamer, Glib, TextureMapper,and etc.

(In reply to comment #3)
> Yes, I also mean that this bug is about sharing the code not sharing the web process. I will change the bug title.

FWIW and FYI, there is already a running effort to increase the code sharing between Gtk and EFL port, specifically about sharing the ATK implementation initially started at the GTK port. More info on bug 99578

[Dan Winship]

Yeah, when I suggested this, I had thought that all the rendering stuff was on the UIProcess side, and so the WebProcess mostly just consisted of platform-independent code and the soup backend.

Not sure there's a huge advantage to sharing the main() between the two implementations...

[Michael Catanzaro]

EFL port has been removed.