- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
Making it Build
Hello fellow Haiku'ers, as promised I'm posting a quick update on my WebKit / WebPositive contract work. It's been a little more than a week already, and a small report is due!
Welcome WebKit r115944 ! As you may know, WebKit is a really big project, in the last two years, 70000 revisions have passed and the file count has almost doubled. The approach I took was to start by checking out a recent WebKit revision and try building the components one by one, re-applying our changes. The idea was to add only the strict necessary for Haiku and at the same time try to include as many features as possible, ignoring assumptions and workarounds that aren't needed anymore. As many things have changed in WebKit and as I needed to get familiar with this huge codebase anyway, I decided to dismantle our port and put it back together again, like one would have done with a complex piece of mechanics. Thus I did a Jamfile from scratch, based on other platforms buildsystems, and replayed our changes one by one, as the compiler asked. Each time trying to document my changes and research the reasons and implications of the changes.
WebKit is composed of several distinct parts, as seen in the source tree:
WTF (Web Template Framework) provides base utility classes for all the project, it's pretty much platform agnostic and only few changes were needed to make it build again. It took me a day to get it to build again on Haiku.
JavaScriptCore, the default javascript engine took a bit more care, but a day was all that was needed. Tests run, at least as well as on other platforms it seems, but I'll get back to it later. The javascript shell 'jsc' works well too, and I could run http://v8.googlecode.com/svn/data/benchmarks/v7/run.html benchmark and be pleased with the results. It seems that the situation really improved, under Haiku at least. See for yourself:
old current Richards: 784 5295 DeltaBlue: 726 4483 Crypto: 463 5305 RayTrace: 1985 8026 EarleyBoyer: 1803 6355 RegExp: 1121 2593 Splay: 2430 6723 NavierStokes: 780 4242 ---- Score (version 7): 1091 5124
Next is WebCore, where the real meat is. This one took me around ten days (yes, I had already started before posting my contract proposal, if only to estimate the work needed) to get it in back a buildable state, following the same approach, trying to understand even the smallest change. I have no way to test if it behaves as expected yet, but I'm at least confident that I haven't devied too much functionally-wise. I'll get back to it when I have a browser to play with!
And now the WebKit part, which mainly contains the client API to build browsers, HaikuLauncher test application and WebPositive sources (that will be moved in the Haiku source tree at some point). It contains some fat classes, but it's not as heavy as WebCore and when that one builds I'll be finished with this first phase of 'Making it Build'.
So that's where I am, WTF and JavaScriptCore can be considered done, there's a lot more uncertainty on WebCore but I believe that when I've got libwebkit built and a test application running (in a couple of days hopefully), it shouldn't be too hard to bring it back to a more solid state.
You can follow my progress on my github repository https://github.com/aldeck/haikuwebkit (more a personal backup than a real collaborative repository as it's a git-svn clone of our current haiku-webkit svn repository)
Hope you enjoyed this piece of text, I'm for one really enjoying working on this project :-)
Best regards,
Alex
- aldeck's blog
- Login or register to post comments

Comments
Re: Making it Build
Nice work.
Thank you for the report on your efforts so far. Do you plan on making any feature additions to WebPositive, or are you just updating it to a new WebKit?
Re: Making it Build
Thanks, In the end that's the plan, but i won't make any promises :) Not for this one month contract at least.
Score
Thanks for the information!
Firefox 13 on Windows XP:
Haiku WebKit port is r115944 . Newest WebKit is r119533 ... It's a pity that, Haiku is not growing so fast. Maybe we should hire someone, who will deal with only the WebKit port? :P
Re: Making it Build
Be careful, that's on a i7 3770K :-) those results depend on your hardware. On my machine, the final score on Firefox/linux is around 10000 and Chromium/linux 14000! I'd have to build jsc on linux though to measure the same thing.
Re: Making it Build
Awesome, this sounds great. As someone who has worked on our WebKit port before I appreciate your fresh approach, and I think in the end it will result in a cleaner code-base. I only wish you could have had time for this contract earlier, but better late than never.
I think in the end this contract will be money very well spent. Thanks for working on it for such a reasonable (pretty small really) contract rate!
As for the speed of JavaScriptCore, I suspect there is still plenty of room to optimize our port. For example does your new JSC use the JIT compiler? I know we never had that turned on before. Also while now I think using JSC is the quickest way to get a working browser, some day we could investigate using V8 if the JSC performance is not what we want.
Re: Making it Build
Just as another data point on JavaScript performance, I just ran the V8 Benchmark Suite on both Safari and Chrome on a MacBook Pro, and Chrome really trounced Safari, scoring a total of 11796 to 6783. So again while JSC will give us a reasonably fast working browser right now, trying to get V8 going in the Haiku WebKit port could be a nice performance boon.
But that is definitely outside the scope of your current work, and is probably something I'll look at one day. Another benefit of a working V8 for Haiku is having Node.js working as well.
Re: Making it Build
cool, i like node.js for haiku.
And i love to see a native js haiku api bindig framework (hello HaikuWebOS)
Re: Making it Build
It would be interesting to know, how much effort/time it would be needed aproximalitey to port chrome/chromium to haiku, in case webkit would be already completely ported to haiku.
Because after we have once webkit up-to-date i guess the next step should be chrome.
Re: Making it Build
Don't forget:
https://www.haiku-os.org/blog/maximesimon/2009-06-19/haiku_native_browse...
A Browser with minimal UI and Tabing with S&T.
I like the tile funktion from BeIDE !
Other i love the idear from Plan9:
http://plan9.bell-labs.com/magic/man2html/2/html
http://plan9.bell-labs.com/magic/man2html/4/webfs
Let us go the custom way ( we have a custom kernel! and some other stuff aka packages system ) Why not make a custom technology for html5 and co.
I look back BeOS have some good technology have the same as android or ios in time have, but beos ending 2000 now 12 years later?
Personaly i used ubuntu and i don't love it!
doha lets rock on haiku ...
Re: Making it Build
Yes, as much as I appreciate WebPositive and think it's a nice proof-of-concept project I really don't see it as a viable option when it comes to providing users with what they expect from a modern webbrowser. I feel that a port of Chrome/Firefox is an important step in order to make Haiku a fully useable day-to-day OS and given the effort put into porting webkit it seems clear that Chrome (or rather Chromioum) is the way to go.
Oh and keep up the great work Aldeck!
Re: Making it Build
Re: Making it Build
I was thinking the same. But undertaking such big projects, will have the side-effect that even port of chrome fails, haiku itself will make progess. When doing more complex stuff, and short-coming and the bugs are becoming more visible.
It's clear that chrome will dominate the browser market and perhaps once the webkit port is done perhaps it's a good idea to "try" to port chrome.
Re: Making it Build
I was thinking the same. But undertaking such big projects, will have the side-effect that even port of chrome fails, haiku itself will make progess. When doing more complex stuff, and short-coming and the bugs are becoming more visible.
It's clear that chrome will dominate the browser market and perhaps once the webkit port is done perhaps it's a good idea to "try" to port chrome.
While I really love Chrome and it would be nice to see it on Haiku, I think for a very long time Haiku developers will have more important projects. It has always been my opinion that in the short term it should be possible to clone functionality or even borrow code from Chrome where it makes sense. Right now WebPositive is equivalent to a very early version of Chrome or Firefox or name your browser, and it really isn't fair to compare it to something like Chrome which has had hundreds of full time developers working on it for years. Give us a chance to improve it before deeming it unworthy!
Because no port can ever be as nicely integrated with the operating system as a native solution.
In addition as part of their WebKit2 initiative the WebKit project is creating a more generic version of the Chrome multi-process browser model, and we can make use of that more easily than trying to make a full Chrome port. Plus as I recall it is a better architecture because it is well integrated with WebKit rather than being add on as Chrome's version was.
But I do understand the point you are making, and porting WebKit originally did expose bugs and lacking functionality in Haiku which we added, and I imagine the same would happen with Chrome (actually it was our lack of wchar support which stalled the port in the past, but we have that now.)
Of course if some developer who is new to Haiku wants to take on a Chrome port project, I encourage it, but so far those efforts have not gotten very far.