WebKit weekly report #40

Blog post by PulkoMandy on Fri, 2014-08-08 07:13

Hello world!

This week most of my time was spent working on getting WebKit2 compiling on Haiku. WebKit2 is the new multi-process model for WebKit. It replaces the old WebKit1 that our port uses currently. WebKit2 spawns a new process for each tab, and possibly more (for network access, etc.). The key features are:

  • When a webpage crashes WebKit, only the tab showing this page is lost, not the whole browser
  • The use of more processes makes the application feel more reactive. As you know, the threading model in WebKit is not a perfect fit with Haiku's one, but splitting things in a separate process allows us to have a standard Haiku application as the visible browser shell
  • All the tricks of getting WebKit running (specific tweaks to BApplication and BWindows) are moved to the rendering process. This makes the BWebView API much simpler, as it will become just a plain subclass of BView, with no expectations on the BApplication or BWindow
  • The WebKit2 API is where all current WebKit development happens. WebKit1 lacks support for some features

However, there is quite a lot of code to write before WebKit2 can be run. For a lot of things we can use our UNIX compatibility (threading, spawning processes, and IPCs). But some other things will be Haiku specific. This starts with the "run loop", which will be a BLooper receiving BMessages in our case. I also started implementing add-on support (a first step towards Netscape-style plugins support), and early support for using BBitmaps to send rendered page images from the rendering process to the browser shell. However, this is not quite enough to get things compiling yet, and it may be another one or two weeks before I have a binary to show.

I did some early work on OpenGL support, however I left this aside for now. The simplest way to plug WebKit to OpenGL is using EGL, which we should really add to our Mesa port as it's becoming the standard for allocating GL contexts. This used to be taken care of by platform specific APIs (for example GLX was used on X11), but with the Linux desktop switching to Wayland, and Android and iOS both using EGL, we have little choice but follow the trend here. We will of course keep the existing BGLView API, but EGL support would bring us a more up to date and more flexible solution. Once again, there is some work to do there before we have something to show.

WebKit developers have suggested we try to do this as soon as possible to avoid writing custom rendering code for Haiku, even if our OpenGL is currently software rendered, it would avoid writing and maintaining a lot of custom code for the rendering part. However, I don't know if the performance of software rendered OpenGL would be acceptable. In any case, working on EGL would benefit some other apps as well, and once running, testing the OpenGL enabled WebKit would be much easier.

I also did some work on the existing WebKit1. Only two small changes this week however: waddlesplash provided an improved CSS style for the directory listing (used by the file and gopher protocols, and soon by FTP), which I integrated ; and I fixed yet another bug in the networking code that removed another possible crash. I made the changes to the rendering code in WebKit 1.4 fully optional again, as there were many complaints that they make browsing much slower. I'm still not sure which is the best way to go with that, however. The two rendering modes have drawing glitches in different places and I don't think there is a way to dynamically switch between them depending on the page being rendered.


Re: WebKit weekly report #40

Very nice Adrien, looking forward to the first test binary with webkit2.

And add-ons!!!!! Does this mean it'd be possible to install, for example, Ad-Block, sometime down the road?

Re: WebKit weekly report #40

This was add-ons in the Haiku sense, that is, groundwork for things like the Flash plug-in. Things like ad-block don't need such native support, as they are written as web applications (the code is mostly Javascript). However, they are browser-specific and nothing Web+ can really help with.

Re: WebKit weekly report #40

I currently burn builds of Haiku x86_64 to CD. But, when I try to run WebPositive, it always crashes. Any idea when WebPositive will be working in Haiku x86_64?

Re: WebKit weekly report #40

EGL in Haiku? Yes!!! Dreams are coming true now!!! Pinch me please!

Re: WebKit weekly report #40

*Pinches you* It appears you are not dreaming, michaelvoliveira! Very exciting news indeed!

Re: WebKit weekly report #40

EGL yes... accelerated? probably not.... unless adrien finds himself to be having a good ole time improving mesa :D

Re: WebKit weekly report #40

Well that could be useful too. But I think I can't leave WebKit in the current state and switch my focus to that. Maybe when WebKit is in a more useable state I will consider extending my contract to GL support. But that could take some time... Also, it is probably better to try to get R1 out before starting to work on even more features.

Re: WebKit weekly report #40

As my great aunt says... your plate is full! :D Ive enjoyed reading the timely updates as well!

OpenGL would be nice to have that is for sure... but its not like we haven't waited this long. So, more waiting is not a big deal :) .... (completely off topic but...) I've been fascinated with learning Romanian the past few days (2 Romanians at work... and I already speak Portuguese) its actually quite refreshing to learn another language.

Re: WebKit weekly report #40

So this means that the browser will be similer to chromium in funtionality? Off topic is it possible to use the linux firefox port of flash in some add on/emulator or something?

Re: WebKit weekly report #40

your work on opengl can help to get blender on haiku? many thanks for your work

Re: WebKit weekly report #40

I just updated to the latest nightly (hrev47708) and definitely some nice improvements. For a moment, I wasn't sure if I was viewing my OSX screen or my Haiku VMWare screen. Webpositive rendering is really coming along.

I also noticed that 'favicons' are finally supported...woohoo! :-)

The one thing that was really noticeable is the font substitution on some of the fonts. Is this due to the rendering or just the lack of compatible fonts, or weak/incomplete font matching logic? As an example, try Yahoo.com or apple.com/support for an example.

Otherwise, just wanted to say that WebPositive is really looking good. Very happy to see that WP is becoming a first class browser. In todays computer environments, good web support is absolutely crucial to the usability of the OS.

Keep up the good work! :-)