[Development] Qt WebEngine

[Alexis Menard]

Hi,


On Fri, Sep 13, 2013 at 7:06 AM, Konstantin Tokarev <annulen at yandex.ru>wrote:

>
>
> 12.09.2013, 16:04, "Knoll Lars" <Lars.Knoll at digia.com>:
> > Hi,
> >
> > As many of you know, we've been doing some research on a (chromium based)
> > new web engine for Qt during spring and summer. I wanted to let you know
> > that we've now come to the conclusion that we want to continue these
> > efforts in the future.
> >
> > Please check
> > http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/for
> > all the details.
>
> IMHO, this is a really bad decision. WebKit is a meritocracy-driven
> community project with many large and small contributors, while Chromium
> seems to be driven solely by Google employees. If Google needs to do some
> ground-breaking changes in the engine, they will do it, and don't hope they
> to care about 3rd party products being broken.
>


This is simply not true. Samsung, Intel, Adobe, Opera have been able to
contribute a lot and influence the development in many ways since the fork
date. I speak of experience. Adobe, Intel and Samsung already have
reviewers (Owners).

The problem of breaking was also happening in WebKit, for example Apple
removed the support of Windows for WebKit2 letting QtWebKit alone broken if
Digia didn't help.


>
> >Chromium has a cross-platform focus, with the browser being available on
> all major desktop platforms and Android. The same is no longer true of
> WebKit, and we would have had to support all the OS’es on our own in that
> project.
>
> To run QtWebKit on embedded platform with unsupported native graphics API,
> it's enough to write gfxdriver for Qt 4, or QPA plugin for Qt 5. Basically,
> if Qt works, QtWebKit works too. To run Chromium I will also need to port
> Skia, and maybe other things. IIRC, it does not even support DirectFB out
> of the box.
>

Yes that's one of the things that needs investigation. But in that
particular case of custom hardware with custom graphics driver on a custom
OS I believe QtWebKit is not best suited. Maybe you want to look at the Nix
port of WebKit which is a low level WebKit port requiring Cairo and OpenGL
to run : http://nix.openbossa.org/


>
> >There are many things that are available out-of-the box from Chromium,
> which would require a lot of work for us to support ourselves in WebKit.
> One example, is the whole platform/OS adaptation that we can simply re-use.
> Multimedia and new HTML5 features such as WebRTC are working out-of the-box
> and don’t require any Qt-specific code.
>
> This implies larger size of binaries for embedded users because of massive
> duplication between Qt and Chromium cross-platfrom layers.
>


Yes but given the small amount of resources one needs to be pragmatic.
Maintaining, releasing, updating a web engine is a very resource demanding
task (and full time) and clearly the Qt project doesn't have the bandwidth
to do so. Therefore it needs to seek for alternatives and help. What is
better? A QtWebKit broken, outdated, unsecure or state-of-art engine (with
maybe slightly less capabilities)? Or maybe just nothing?


>
> >As using Chromium simplifies handling the OS integration, this allows us
> to spend additional time to focus on the upper layers to provide a great
> and easy-to-use API and a seamless integration into Qt as possible.
>
> Does Chromium provide any C++ API warranties? You may end up overhaul your
> fancy integration layer each time you update.
>

You can build on top of the Content Shell module which is what Google is
using to build Chrome, what they use to build their Android WebView and
what Opera uses to build their browser. Crosswalk is also based on top of
that.


>
> >We are seeing that Chromium is being developed with very strict control
> on quality.
>
> WebKit also has solid testing infrastructure.
>

The one of Chromium is the one of WebKit basically even improved. Every
patch is tested (with LayoutTests) on Windows, Mac, Linux which is not the
case in WebKit (it was only running with the Chromium port on Linux only
and now run only on Mac OS). The QA team of Google is magnitude bigger than
what QtWebKit had and the quality of the releases of Chromium proves it.
Not to mention the amount of bots running the code in so many different
configurations.

Google has a dedicated security team working on Chromium, QtWebKit never
had that (and all the fixes are not just in core code, but can be in port
specific code).


>
> >Finally, we are seeing that Chromium is currently by far the most dynamic
> and fastest moving browser available
>
> WebKit is moving slower because it has to care about all its ports. All
> significant architecture changes are discussed by community. Chromium is
> fast because they don't care about anyone else.
>

Again a bold statement of somebody who has not participated to the projects.

Before Google forked they were #1 in the project in term of contributions,
many of CSS/HTML features were developed by them. Of course when they
forked then the number of features in development in WebKit decreased a lot
because only Apple (which has a smaller team than Google) is working on
improving the feature set (with the help of other smaller contributors).
Today the code of WebKit is simpler with one port less but again the number
of features landing in Blink is higher not because it's easier due to no
multiple ports but because the number of people working on the project is
higher. Also many features of the WebKit/Blink are not port dependent
therefore even before or after the development speed is not affected.


>
> >One of the fundamentals of Chromium is that all rendering of Web content
> happens in a different process for security and stability reasons.
>
> WebKit 2 multiprocessing model is much better designed and provides stable
> API. Also, single process mode of Chromium in unofficial and often breaks
> (and it's usually worthless to be multi-process on single-core embedded
> CPU).
>

In what way it is much better designed? Chromium has also significant good
features for example the GPU command buffer.

It is true that the single process model is not first class citizen but
that's valid for Chrome, the browser. Be careful of mixing Blink and
Chromium the browser.

Qt integration will be on top of the Content Shell and this single process
mode needs to work because Google needs it for their Android WebView.


>
>
> I hope there will be some folks to keep maintaining Qt port in WebKit
> upstream. Otherwise, NIX port looks like a good alternative, though it
> requires OpenGL-capable hardware.
>
> --
> Regards,
> Konstantin
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Software Engineer @
Intel Open Source Technology Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130913/20ad79c1/attachment.html>