Hi,
On Fri, Sep 13, 2013 at 7:06 AM, Konstantin Tokarev <[email protected]>wrote: > > > 12.09.2013, 16:04, "Knoll Lars" <[email protected]>: > > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > -- Software Engineer @ Intel Open Source Technology Center
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
