WebKit weekly report #36

Blog post by PulkoMandy on Fri, 2014-06-27 07:37

Hello everyone,

Things are rather quiet on the WebKit side this week. I'm reviewing and fixing the remaining bugs with the new drawing code, which is now working rather well. On the WebKit side, I have implemented a limited form of transform support for regions (only handling translation and scaling, not shear and rotations), which has very good results. As a consequence, we now have mostly correct drawing and quite good performance. Before I do a release (I know the version in current nightlies is quite outdated now), I want to fix one more bug, which is the lack of video display on youtube. This is probably a simple fix once I understand why the current code isn't working anymore.

I also did several small fixes to WebPositive, on minor details, but which should improve the experience a lot. Removing a finished download doesn't trigger an error notification, the URL in the address bar is properly formatted, and some other small bugs like this were fixed.

As I said last week, once I release this new version of WebKit I will move on to getting WebKit2 to compile and run on Haiku. The WebKit2 API is where all the fun is happening in WebKit these days, and it provides a somewhat more standard interface between WebKit and application.

I read a bit about the design, and the current implementations use UNIX Domain sockets and X Surfaces for communication between the web and UI processes. The Haiku port will probably make use of BMessages and shared BBitmaps instead.

This separation is good news for us, as it will allow the embedding of BWebView into a standard BWindow. The current port needs a BWebWindow to manage the interfacing of views with the single WebKit engine running all of them. It will also considerably unload the main BApplication thread by moving all of WebKit to a different process. This will lead to much easier and cleaner integration of BWebView in existing applications, and will also make it much simpler to provide a BWebView API that is abstracted from WebKit internals, meaning it will be easier to turn it in a stable API, which can then be made public. I hope we will then see 3rd-party web browsers making use of this API to provide more functionality than Web+, which I think can remain the simple default browser.

Comments

Re: WebKit weekly report #36

Hi.
I know I repeat myself.
But instead of starting to work on webkit2, I think you should start working on blink.
I think we intuitively know that google is better at open source than apple, and that google was more power and a bigger determination. We see how big google is, and it's still growing. It's still entering new domains, and it's still innovative.
Opera is a big expert in that domain of browsers, and they didn't switch without very good reason. The same is true for QT.

I think, before starting to work on webkit2, perhaps you should make a pool, to ask the users what they want. If they are paying, then they should decide if webkit2 or google blink.

Re: WebKit weekly report #36

cipri wrote:

Hi.
I think, before starting to work on webkit2, perhaps you should make a pool, to ask the users what they want. If they are paying, then they should decide if webkit2 or google blink.

Part of the issue with pools is to appreciate exactly what are the options presented.

From an and-user perspective, I don't really care whether it is webkit, webkit2, or blink which is the underlying framework for the web browser interface.

Nevertheless, you are bringing a good question - one of long-term directions for Haiku - not just Haiku it-self but also some of the key apps one needs/wishes to make Haiku more than just an interesting and promising hobby operating system.

Re: WebKit weekly report #36

The difference of opensourceness between Apple and Google is not as big as most people seem to think. Apple has a long histor of releasing many components of their operating system as opensource. This includes not only WebKit, but also XNU/Darwin, the Objective-C frontend to GCC (in NeXT days) and now contributions to clang/llvm, and so on, Yes, the UI part of their system is closed source, but then, so is Google Search. While Opera and Qt have switched to Blink, WebKit is still not an apple-only project. In the main subversion tree there are ports to GTK and EFL. The GTK port is supported by Igalia, and the EFL port is supported by Samsung and Intel, as part of the Tizen project. Intel is known to be very supportive of open source, much more than Apple and Google. Anyway, aside of these political discussions, the problem is technical. Blink is designed to run on a platform abstraction layer which disconnects it from the underlying platform. This means it doesn't use the native font rendering, the native network APIs, the native windows, or native anything. It needs a lot of support to do anything useful. This support is implemented, for example, in the Chromium web browser. So, we would need to port not only Blink, but also Chromium. And doing so, the BWebView API would have to go away, because there is no way to embed Blink in another application in this case. We could get it to work, but it is essentially starting a new project from scratch. On the other hand, moving from WebKit1 to WebKit2 allows us to use our existing port with few changes, and get something running without too much work. As you can see, the decision cannot be made only on the base of "who is the coolest company around". Blink and WebKit have different goals (otherwise the fork wouldn't have happened), and different techical challenges in porting them. If you think about it, you will notice that Apple, GTK and EFL are not working on web browsers. They are working on a web engine that can be bundled inside an OS, and used to build a web browser, or any other application that needs to render HTML pages, possibly mixing them with native widgets. WebKit is very suitable to this, and will allow us to build a "Web Kit", to put next to the other kits in the Haiku API. Because of the design of Blink, we would never get an integration as tight as that with it. Finally, Blink is hardwired to Skia and a few other dependencies, which would need to be ported first, and added to the Haiku images. Some of these replicate existing functionality in Haiku and would be of little use. For example, Skia is essentially the same as agg which we have in app_server ; however Skia is better when used with OpenGL acceleration, while agg is tuned for software rendering. So, to get something useful out of Blink, we would first need to port Skia and probably also get OpenGL acceleration running. While possible, this is certainly a much longer term project than moving from WK1 to WK2. I think you now have a better idea of why I'm going towards WebKit2. That being said, my contract with Haiku, Inc. is open-ended, and if there are strong arguments for working on Blink, I could do that as well.

Re: WebKit weekly report #36

Hey!

Good to hear the next webkit/web+ release is taking shape. Can't wait for the release! :)
Does WebKit2 also mean a multi-threaded web+, like one thread per tab or maybe even multi-threaded rendering per tab?

Thanks for your great work!
Humdinger

Re: WebKit weekly report #36

Using WebKit2 opens the possibility of using multiple processes for web views. Note that is processes in not threads, which makes sense to protect web views from each other. The actual policy for deciding that a new web view will have a separate process is up to the port. I have added some months ago the API in the WebKitGTK port for this, and it allows to keep use single or multiple processes for web views, or to let the application decide what to do (we have API for that).

Is is great to see that Haiku may be moving to WebKit2 at some point. WebKit2 has been working way better for GTK and EFL applications, and it would be great that Haiku used it to gain access to new web platform features which are not likely to be implemented in WebKit1 :-)

Re: WebKit weekly report #36

PulkoMandy wrote:

The difference of opensourceness between Apple and Google is not as big as most people seem to think. Apple has a long histor of releasing many components of their operating system as opensource. This includes not only WebKit, but also XNU/Darwin, the Objective-C frontend to GCC (in NeXT days) and now contributions to clang/llvm, and so on, Yes, the UI part of their system is closed source, but then, so is Google Search.

I do disagree here, WebKit was formerly known as KHTML and LGPL licenced, and Apple has come under fire for delaying releasing their contributions to Webkit on several occasions.

XNU/Darwin was indeed open sourced, however they chose to release it under their own copyleft licence which meant that the BSD's could not use it, and since it was also incompatible with GPL one can't but wonder if the whole idea from the start was to release it in a way that would severely limit it's potential, and indeed the XNU/Darwin based offsprings have quickly died due to lack of developer interest.

The objective-c frontend in GCC is particularly illuminating as Jobs (at NeXT) wanted to keep the frontend proprietary while using GCC as a backend, claiming that the end user would do the linking, the FSF lawyers disagreed and that is why GCC got a objective-c frontend, not due to any kindness on the behalf of Steve Jobs or NeXT.

And there's a lot more than the UI part of their system that is closed source, XCode is proprietary, Instruments which is their fork of DTrace is proprietary, their new graphics API metal is proprietary and of course their new language Swift is proprietary, compare that to Google's Go language which has been open source from the day it was released and portable to any platform, with a Haiku port in progress as part of Google's Summer of Code no less, and of course just the Summer of Code project itself puts Google WAY ahead of Apple in terms 'opensourceness'.

So I certainly disagree with you here, on the other hand I agree with you on Blink (apart from the OpenGL thing, AFAIK Skia has a fully working cpu software rasterizer), with all the work done on porting WebKit to Haiku there is no point in jumping ship, atleast unless something drastic would happen, like Apple no longer contributing to the open version of WebKit(2), but that seems unlikely.

On a different note, thanks for the great work on WebPositive, keep it up!

Re: WebKit weekly report #36

Rox wrote:

I do disagree here, WebKit was formerly known as KHTML and LGPL licenced, and Apple has come under fire for delaying releasing their contributions to Webkit on several occasions.

Actually KHTML is still maintained and used in KDE's Konqueror browser. Apple merely forked it. I would have thought contributing to that project would be more worthwhile because it would avoid Apple/Google/Mozilla politics, but maybe its not really viable from a business standpoint ATM.

Re: WebKit weekly report #36

I don't know the internals of webkit2 vs blink. But I see that chrome is working pretty well, and seems that it works better than the "native" webkit on windows and linux.
Then you say that blink is not that easy to integrate into a "webview", so that one can build this into the kit of haiku. But QT is doing exactly this with blink, and this even bring major improvements to qt (it's going to be included in qt 5.4).
The fact that google is doing more abstraction and doing more stuff on their own, has also the good benefit, that we don't have to worry about that things on ourowns. As you know the network kit is incomplete, buggy.. etc...

And I think, one should not neglect that fact that chrome is very dominant at the moment, and it's going to grow even more. It has chances to becomes nearly something like IE in the 90s.
In many countries it has already a marketshare of 70% - 80% !
And it's still growing. It's working on android, and it's very likely going to be the default browser on android.
The synching on chrome works very good (bookmarks, passwords, etc...), and it's something you will miss in haiku if you are used to chrome. And more and more people are going to be used to chrome. Chrome is big, but still has the biggest potential of growing! If i remember correctly webrtc also works best on chrome (I think there are some problems/bugs in some cases on firefox).

Working on webkit2 is fine too... but it seems that google is the future.

Re: WebKit weekly report #36

Now you are talking about Chrome, just not Blink. While having Chrome (and Firefox and Opera and...) on Haiku would be nice, I think this is a project to be handled by the Chrome team. What about asking them for an Haiku port?

Re: WebKit weekly report #36

I'm talking about blink, with the idea, that later this would help at a later point to port chrome. So yes, in the end chrome would need to be ported. But at the moment it would be "enough" (more than enough) to have blink as a backend for webpositive. In the end I don't see how we could ignore chrome. If we had already blink, perhaps it would be also more likely to be supported by google directly. I guess from apple you can not expect any direct support. In the end google already donated money to haiku, while apple did not.

Re: WebKit weekly report #36

I guess I'm not a person who's supposed to be a part of this discussion but I have this little question.

"The fact that google is doing more abstraction and doing more stuff on their own, has also the good benefit, that we don't have to worry about that things on ourowns. As you know the network kit is incomplete, buggy.. etc..."
Isn't this way of doing things pretty much against Haiku-way of doing things?

I remember someone saying a long time ago that they could port some libs, get some glue and voila! 100% non-native WebKit port but it works! And I also remember PulkoMandy talking about things like improving the whole Haiku OS while working on WebKit port. Maybe the Network Kit is incomplete and buggy but... isn't it the best moment to take care of it and if it could be fixed and improved while there is work done on WebKit port? All other software for Haiku would benefit from it actually.

Re: WebKit weekly report #36

PulkoMandy,

Excellent work.

I hope there will be an announcement once the nightly incorporates the current port.

I have some unexpected free time ahead and I'm really tempted at trying how well it meshes with edX.

Re: WebKit weekly report #36

From my experience working in the WebKitGTK port of WebKit2, it will is very difficult to untangle CoreIPC from the rest of WebKit2. This means that you will not be able to use BMessage for inter-process communication. That being said, some WebKit2 APIs can be only be used either from the UI process (the application), some others only from the web process that implements the rendering (for example, DOM bindings), and that means that some additional communication between processes might be needed, but that is left to the application. In the case of Epìphany (the GNOME Web browser) we use D-Bus for that, and using BMessage surely would fit for that task.

Cheers, and keep up the good work!

Re: WebKit weekly report #36

uhh long words and coments making brain hurt. all of this could be reduced to youtube is not working, instead all the end users are going what are they talking about I don't care about all this crap. again I am not trying to be rude, but god we don't want to see 5 long comints and then ask a question and get yelled at for not reading all the dum long comints that we don't understand anyway.

Re: WebKit weekly report #36

Linuxgamer94 wrote:

again I am not trying to be rude.

So it all comes quite natural to you...
Reading your comments, I can't help but think of the saying "Better to remain silent and be thought a fool than to speak and to remove all doubt."

Regards,
Humdinger