The goal of this document is to be an overview of everything I did during GSoC. It should be readable even if you haven’t read any of the previous blog posts and don’t know much about Haiku or WebKit (I hope I succeeded!).
First, some background. Haiku’s native browser is WebPositive.
WebPositive’s code mostly deals with the user interface. It uses our fork of WebKit, HaikuWebKit, to actually render the web pages, run JavaScript, process input, and so on.
So I’ve implemented mouse support. It also turned out to be really easy to fix text rendering. So, what’s next? Well, some websites like https://discuss.haiku-os.org cause WebKit to crash. This crash also seems to affect other websites. Really, it seems to occur anytime WebKit decides to use multiple bitmaps (actually, in WebKit lingo, backing stores) to render a web page. Rendering a single bitmap is easy, just display it! But when you have multiple, you need to composite them together.
Success! Now MiniBrowser displays things once again. Here is MiniBrowser showing https://review.haiku-os.org/
So, yeah, there’s still plenty of work left to do. Text isn’t rendered properly, keyboard and mouse support is missing, the window can’t be resized without MiniBrowser crashing, and it crashes when exited. I’ll take it one step at a time. Let’s make the mouse work! Then I can actually click on stuff. I think implementing that will be straightforward.
WebKit wasn’t trying to draw anything to the screen. Turns out, it wasn’t aware that it was visible. No use drawing a web page when you’re invisible, right? Well, I told it that it is visible, and now it’s trying to draw to the screen. Of course, it crashes while trying to do so. It hasn’t tried to draw to the screen in ages. Everything is bit rotted!
So far, it looks like this will mostly be a collection of minor tasks.
WebKit is split into several processes. One of these processes is the browser itself. In my case, this is MiniBrowser, but, hopefully, in the future, it is WebPositive. Since browsers can have any name, WebKit refers to this process as the UIProcess. And, indeed, that process is mainly responsible for the UI. Our port will also be using two other processes: NetworkProcess and WebProcess. Unsurprisingly, NetworkProcess does the networking. WebProcess does all of the work associated with a single web page.
Currently, MiniBrowser (the simple browser that we use to test WebKit2) crashes rather easily. It crashes when it is closed, but that’s not too bad. Unfortunately, it also crashes when trying to navigate to a website (shown above)! I will be working on fixing this crash first.
For those who aren’t familiar with WebKit’s code, that’s all I can really say. But if you are familiar, then keep reading. WebKit wants to know how I will fundamentally approach porting WebKit2.
WebKit builds can take a lot of space and time to build on Haiku.
To those working on WebKit, welcome! This blog post is primarily for those working on HaikuWebKit, Haiku’s fork of WebKit, but it may also be useful for you. I will be covering some techniques that are useful to reduce the size of build files without significant disadvantages. I’ll also cover how to speed up linking.
So I got accepted into GSoC again! I’m going to be working on WebKit2. But what is WebKit2, or even WebKit, for that matter? Well, WebPositive uses WebKit to render its web pages. Currently, we use the WebKitLegacy API to communicate with WebKit. It would be nice to switch to the newer version: WebKit2. However, our port of WebKit2 still needs work. At present, it has lost its ability to even render any webpage at all!
What is Icon-O-Matic? There’s a good chance that not everyone reading this article will know what Icon-O-Matic is, so I’ll start by explaining what it is. Icon-O-Matic is a vector graphics editing program like Illustrator or Inkscape. It is specifically made to work with Haiku’s custom HVIF vector graphics format. This format is similar to the SVG format, except optimized to be much, much smaller. The blog post “500 Byte Images: The Haiku Vector Icon Format” provides a more in-depth discussion for those interested.
While the change request to add reference images was being reviewed, I started working on ticket #18415, which suggests adding shear and perspective transformations. I decided to implement the perspective transformation since I still need to figure out which way I’m going to implement the shear transformation. Hopefully the experience in implementing the perspective transformation will give me information that will help me decide how to implement the shear transformation.
