WebKit weekly report #50 - One year of WebKit!

Blog post by PulkoMandy on Fri, 2014-10-24 07:33

Hello everyone!

This week is a bit special, as it closes the first year of my contract with Haiku. I wish to thank everyone for their support through donations, bug reports, comments on these articles, and general support for my work. I hope this will continue into next year.

This was again a rather busy week, but there was not much work on WebKit itself. I'll keep the breakdown I used last week (haiku/haikuports/webkit) as it seems to work well.

Changes in Haiku

I worked on several things in Haiku this week, some of which could be considered "off-topic". I'm trying to remove the most obvious bugs and make things more ready for a release. This started last week with the screensaver fixes, but there is more this week.

There were some missing checks in BNetBuffer which could lead to a crash in out of memory conditions. It is fixed now.

The Canna input method was removed from our source tree as there is now a package for it in the haikuports repository. This closes the work on making the input method work again after the merge of the package manager.

I started investigating the issues with MediaConverter which fails to convert most files. First I'll give some explanation of the situation here. MediaConverter is a simple application, which is used to convert media files (sound and videos) from one format to another. It is bundled with Haiku and uses the Media Kit to do the work.

Our implementation of encoders and decoders in the Media Kit relies on "plugins". These are add-ons loaded in the application address space to perform the actual work. the Media Kit provides a common API to all the plugins, allowing applications to read and write any format easily. Haiku currently includes only one plugin, which is based on FFMPEG. This is used for all the decoding and encoding work, and it works fine for example in MediaPlayer. However there is something going wrong with it, because MediaConverter will fail to encode anything, and either crash or output an empty file.

I first wanted to test encoding with another one of the plugins. We have several that talk directly to different libraries instead of going through ffmpeg. I started reviewing and fixing the Musepack one, but I noticed it doesn't support encoding. None of our plugins besides the ffmpeg one does! So this left me with only ffmpeg to test with.

Then I had a look at the ffmpeg plugin code. There is a list of supported encoding formats, so I decided to try a few more of those to see if I could find something relevant. I found that the FLAC encoding works fine, but anything else I tried fails or crashes. So in a current version of Haiku, you can at least encode to FLAC, and the other formats are disabled. This only exposed more issues in MediaConverter, however. While the encoding works fine, there is a problem with handling the end of the file, and as a result, a few seconds of audio go missing from the output file.

Since it is not easy to debug things in MediaConverter, where issues can come both from decoding the source and encoding the output, I started looking at the tests for the media kit. I found that most of them were not converted yet to the unit test framework and started doing so. A comment in one of the tests reminded me of an issue I had introduced earlier and forgot to fix. BMediaFormat::GetFormatFor works again and this will help Colin continue his work on DVB support.

While researching these media issues, I tried generating some test tones with Sawteeth. I exported those to AIFF and found that MediaPlayer would play only noise. This was also a known issue, but everyone assumed it was a bug in ffmpeg. I decided to take a closer look and found the bug was actually on our side, and I could easily fix it. Basically, we were computing the endianness of the samples, but not using it at all. This is now fixed and playing AIFF files works again. While I was at it, I also fixed the sniffing rule so it actually detects AIFF files correctly.

I then started investigating the problem with ogg encoding more closely, and looked at different ffmpeg versions. I found that the error we were hitting was an overflow of a static buffer, which was removed from later versions of ffmpeg. So I decided to have a try at porting ffmpeg 0.11 and trying to encode using that version. It was a bit more work than I expected to get ffmpeg 0.11.5 to run on Haiku, and in the end I hit an apparently different error. The ffmpeg team added a new safety check, and we are hitting it. We are feeding the vorbis encoder with integer values, and it can only use floating point. This shows there is a problem with the format negotiation between our encoders and decoders. I didn't have time to see if I could fix this. I will do more testing with the new ffmpeg, as the previous attempt to update to 0.11.1 led to breakage of video replay in Haiku. I think this is fixed now (at least youtube seemed to work) so we should attempt an update again.

Now come some interface kit fixes. I noticed that the "stop" sign in the ScreenSaver preflet was not drawing correctly. This sign is used for the "active corners" view. It turned out to be a matter of enabling subpixel precise drawing and removing unneeded rounding.

I also fixed an issue with BMenu, which would crash if an application changed the selected item in a radio menu while the user was browsing it. Not a common case, but there was no reason to crash, anyway.

Finally, I fixed an issue in agg. Trying to draw a curve with one of the coordinates set to NaN (not a number) would lead to an infinite recursion in agg, freezing the app_server. This issue was first discovered with the Firefox port, was reproducible for some time with a test in WebKit, and finally started happening with NetSurf when browsing to some pages as well. It was fixed independently by some other people using agg, but unfortunately the development of the library is not very active anymore (the main developer stopped working on it in 2006). So I merged the fix in our copy of agg for now.

I also did some work on fixing compiler warnings. We have a goal of absolutely no warnings in our source tree, but we are doing this one component at a time and slowly fixing the issues. And of course, compiler updates (newer versions of gcc4 or clang) make new warnings appear, as well as ports to new CPU architectures. So this week I fixed warnings in all video card drivers and enabled the compiler switch that turns the warning into errors for those. No functional changes, bugfixes or new shiny features, but it makes sure the code stays clean and safe.

The BMessageFormat class started getting some use, and I got bug reports about it. It was fortunately a simple fix and things are working correctly now. As such, Polish and Russian (and a few other) translations can finally get correct plural forms in UI messages.

I fixed a small, but very annoying regression introduced by the outsourcing of Bash. It had stopped adding a / when tab completing a directory. Small change, but very annoying when you are used to it. It turned out to be a missing setting in our default readline configuration file.

I rewrote BNotification preferences and server to use a single settings file instead of 3. No functional change here, just some cleanup.

And finally, something related to WebKit: I fixed handling of file URsL for files with the '+' character, and added more support for IDNA (unicode in domain names) to the BUrl class.

Work on HaikuPorts

Various things. Besides the already mentioned ffmpeg 0.11.5 port, I added recipes for gptfdisk (currently not working), libuuid, and fixed the recipe for Paladin (pointing to the WIP 1.4 version at HaikuArchives).

I fixed an issue with OpenGL and SDL which would make apps render in a 32px area in a corner of their window, and finished work on the DragonMemory recipe using this fix. I also added a recipe for BeBRexx, an implementation of Rexx (Amiga users know about this one) with support for BeOS scripting (like 'hey').

Work on WebKit

The most important part is work to enable the HTTP part of the WebKit testsuite. I had completely missed the fact that WebKit had an HTTP testsuite before. This was pointed to me in the comments for one of the patches I sent to WebKit bugtracker. This testsuite needs a webserver with php and cgi support, and can use either lighttpd or apache 2. I decided to use lighttpd, which I know as I use it on my linux servers, and it is quite easy to port. PHP is more of a problem, while I could get it to compile after some build script hacking, the resulting php-cgi binary will KDL the system. I tried some older versions, but they all have the same problem.

Until this gets fixed, I'm using the old PHP 5.2 for BeOS port I found on Haikuware. This one seems to be working fine, and can be used to run the testsuite. And the result is the testsuite found a crash in our WebKit network code and several tests are timing out. I will have to fix those now.

This new addition to the testsuite also exposed a problem in the webkit testsuite harness, where we would sometimes fail to dump results at all for some tests. I already fixed this one, and this increases our testsuite score a bit more. There is still a lot of work to get all tests passing, however.

And that's all for the WebKit side. I have let it rest a bit while I worked on issues on Haiku side.

To close this report, I remind you that next week is the BeGeistert coding sprint, so I will be working from Düsseldorf Youth Hostel, with several other Haiku developers. A BeGeistert coding sprint report will thus replace my usual report.

Comments

Re: WebKit weekly report #50 - One year of WebKit!

Happy anniversary, Adrien! Will there be cake at BeGeistert? :)

I very much enjoy your regular reports and even more so your work over the past year. Since pretty much everyone else of the usual crew is currently very low on Haiku time, your continuous commits are heartening to see!

Thanks very much and onwards with the next contracting year!
Humdinger

Re: WebKit weekly report #50 - One year of WebKit!

How many people are expected to show up for the code sprint?

Re: WebKit weekly report #50 - One year of WebKit!

There'll be 5 guys (Adrien, Ithamar, Ingo, Colin and Oliver) for the code sprint. \o/

Regards,
Humdinger

Re: WebKit weekly report #50 - One year of WebKit!

I definitely agree on Adrien's continuous commits being heartening to see.

Also, if there is a good turnout at BeGeistert, then make sure someone takes a lot of photos for future marketing purposes!

Re: WebKit weekly report #50 - One year of WebKit!

What a lot of great forward progress, congrats!

Re: WebKit weekly report #50 - One year of WebKit!

"Until this gets fixed, I'm using the old PHP 5.2 for BeOS port I found on Haikuware."

Nice to see you still use Haikuware and find the files useful. I remember a time when you said 'I will never use the crap on Haikuware". ;)

Re: WebKit weekly report #50 - One year of WebKit!

Congrats on the year of work!

Perhaps once the Webkit2 port is stable enough you can focus on OpenGL and/or getting FFMPEG up to a recent version.... 0.11 is ancient and sounds like the code has improved in recent versions no use living in the past right :)

Re: WebKit weekly report #50 - One year of WebKit!

Hi, There is a recipe for ffmpeg 2.3 already available (for gcc4). I think it should work fine, but the ffmpeg media plugin may need some more adjustments. Otherwise this should work fine.

Re: WebKit weekly report #50 - One year of WebKit!

Great work, very nice and promissing!
Could you get a look on this website, pls?
Plenty of glitches, you may work on!

http://try.jquery.com/levels/1/challenges/1

Thanks for your patience!

Brüno

Re: WebKit weekly report #50 - One year of WebKit!

I find it rather supprising that my 3Ghz athlon x2 can't play a 360p video without lagging unfortunately... I guess its due to the offscreen rendering for html5 video and shoveling buffers around lots of flickerin as well which you can see http://www.gh0stwriter.net/music/ but I guess these are known problems.

In case it matters this is on an Nvidi 6150 so not particularly impressive but it should at least be able to display 720p no problem.

Re: WebKit weekly report #50 - One year of WebKit!

I suspect there are some serious bugs when using Haiku with AMD based systems. Previously I was using an Intel Core 2 Duo based system and it was relatively trouble free, and I could even play AVCHD videos with MediaPlayer. As soon as I switched to an AMD based system I started experiencing a lot of freeze ups with previously working USB devices and many more KDL's. The AVCHD videos which had previously played OK on the Intel system, now stutter badly.

Re: WebKit weekly report #50 - One year of WebKit!

Could just be the AMD system is significantly slower... AMD just doens't have the singled threaded throughput that Intel has.

Re: WebKit weekly report #50 - One year of WebKit!

Hi Adrien, thanks for all your work and writing about it! I may be stating the obvious, but when I worked on Media Kit Encoding, the formats which were specifically enabled all worked. MediaConverter was added to the tree by me specifically to show off the new Media Kit encoding. But updates to third party libraries frequently break things. I understand why updates are necessary and they are done with the best intentions, but it seems there is always breakage. Sometimes more stuff breaks than is fixed by the update. You know, even WebPositive degraded between the time I last worked on it and when you started, for example by upgrades to cURL. You should take that into account when looking into these things and especially when writing about them, so there is no impression that this stuff never worked well before. For example, when you try to find out why a certain media format is broken, and you find that there is actually a header enabling only very specific formats from the plethora of formats supported by ffmpeg, an alarm should go off in your head which says: "Oh, these are probably enabled, because they were tested to work well. The first thing I should do is look into changes done when upgrading ffmpeg."

Re: WebKit weekly report #50 - One year of WebKit!

"You know, even WebPositive degraded between the time I last worked on it and when you started, "

I find it's a mix of improvements and degradations (which is more frustrating than either a degradation or improvement!) which I am sure many will agree, is valid for the prior software available and entire operating system as well. We all appreciate Adrien's work and thank him for that; I think he's learning a lot, and at the same time needs more contract time. Developing Web Positive is a huge endeavour for one person! So lets give him that credit :) Lets not be too negative, these huge projects take time. Adrien is one of the only developers pushing packages of all sorts to the Haiku Depot regularly (without him it'd be a joke).

It's just a lack of resources and developers for Haiku. I have some laptops that will boot Haiku Alpha II and not Alpha IV or the latest nightlies. It's unfortunate. Haiku just needs more cash behind it so it can hire more permanent developers with real wages and established non open-ended contracts that demand and achieve results with the limited resources available (you can either lay a brick or can't, make my lighting work or not, make my toilet flush or not, no in-betweens IMHO). I tried to argue that the BOD at Haiku Inc. could do better, or at least public elections could be held so that fresh ideas and changes could come in; but it was all to no avail. It's a closed system not accepting new ideas or directors like me (potentially) that have a track record of achieving at least some results for Haiku (programming aside). Cash is the one thing that motivates everybody; as much as we hate to admit (meaning the not for profit developers that invested all their blood & sweat into this platform), it's a necessity. Money talks - Haiku needs more, that's at least something we call all agree upon no? :) (as opposed to bounties vs. contracts). I will further emphasize, there's no harm in posting a bounty or goal-defined contract for $30,000 - $50,000 (if Haiku Inc. budgets accordingly therefore) to fully integrate Webkit natively into Haiku up to Webkit rev. #x. This could be really attractive (if you think those figures are ridiculous, calculate how much has already been spent on the contract). It's a commitment that is not mutual, and entirely on the developer. It's cost efficient. Maybe someone can do it, maybe not. If they don't complete the project it's no loss to Haiku Inc's resources. I realize it is a risk-reward endeavour, but the developer realizes this, or should, also. He has the same right to spend or 'waste' his money at the casino or not (not that this should draw parallels, bounties had a >40% completion rate, far better than a slot machine). I realize most Haiku developers see comfort in the open-ended Haiku contracts where they're free to do what they want, when they want, and in the comfort of their own home. Sure, who wouldn't want this! Even at their accepted rate of pay (which is agreeably sub-optimal) they want to, and do define their own terms of employment and be their own boss working on or fixing whatever they see necessary, that fits within their view of the 'contract' or is selfishly beneficial to them (it's clear most all developers that take on a Haiku contract have primary employment elsewhere and Haiku is of a secondary concern and supplemental/'bonus' income) or *may also be beneficial to the community.

Essentially, what your almost always left with at the end of open-ended contracts, regretfully, is something that doesn't work fully, and someone else has to fix, as Stippi mentioned (i.e package management) Wifi, WebKit, and the record, etc. also quite clearly show this)! Ask Stippi how many man unpaid man hours he's put into Package Management after the ~$20,000+ of open-ended contract dollars that were spent on it... If there's evidence to counter this, please provide it. This emotional, social, personal, and charitable way of Haiku Inc's. funding related contracts needs to end. Results from goal established contracts are needed, not social welfare.

A good example was the Wifi Bounty with Axel Dörfler. The goals were established, yet Axel was unable to provide results. Axel later saying: "In the case of my bounty project, I ran out of time, and tried to make it work - that's stressful and unrewarding, and eventually led me to abandon work on that thing altogether. mmlr later debugged my work, and applied the one-liner that made it work."

Although, claiming the fix was a 'one-liner' debugged weeks later, the bounty and work together was 100% useless to the average user. Under pressure, I bowed to releasing the funds for Axel's work, but this shouldn't happen. The code could have stayed in the repository forever, useless to average users (like package management up until Stippi's alterations). Fortunately it was fixed by mmlr and the code was useable thereafter. But, lesson, learned, one must be firm and stick to established pre-determined contract goals. Otherwise, all the donated money would go to waste. It's not what the donors signed up for.

I think there just needs to be clear defined goals with the resources available to Haiku Inc. at the moment, IMHO. When they have millions to waste, then this open-ended contract model may be applicable to some employees. Yes, defined contracts with goals or bounties are a dirty and efficient way of getting things done when they work; but after a generation, or far less, few remember how the war was won anyways - just who won. We are the 1-2% that knew what BeOS was, the other 98-99% Microsoft and Windows. I know this won't change anything, but I try to make my opinion heard anyways :)

I was actually hoping that guy that mentioned porting many of Haiku's components to Linux would in fact present his findings at Begeistert, but this was also a farce apparently. Poor Haiku, I saw that as a lifeline for hardware related issues.

Re: WebKit weekly report #50 - One year of WebKit!

-1

Re: WebKit weekly report #50 - One year of WebKit!

humdinger wrote:

-1

Totally agree

Re: WebKit weekly report #50 - One year of WebKit!

If you really want the return of bounties then add one to Freedomsponsors or have a call to action for one on Haikuware. Freedomsponsors takes a 3% commission on donations or a 6% commission on donations if paid by credit card.

They also have a trac plugin that allows people to sponsor bounties within trac.

https://freedomsponsors.org
https://github.com/freedomsponsors/freedomsponsors-trac-plugin

Re: WebKit weekly report #50 - One year of WebKit!

kvdman wrote:

"You know, even WebPositive degraded between the time I last worked on it and when you started, "

I find it's a mix of improvements and degradations (which is more frustrating than either a degradation or improvement!) which I am sure many will agree, is valid for the prior software available and entire operating system as well. We all appreciate Adrien's work and thank him for that; I think he's learning a lot, and at the same time needs more contract time. Developing Web Positive is a huge endeavour for one person! So lets give him that credit :) Lets not be too negative, these huge projects take time.

I hope you have not misread what I wrote, because you argue as if I wrote "between the time I last worked on it to now". But I wrote "and when you started". So what I said is that WebPositive degraded before Andrien started to work on it. I am not criticizing Adrien's work.

kvdman wrote:

Essentially, what your almost always left with at the end of open-ended contracts, regretfully, is something that doesn't work fully, and someone else has to fix, as Stippi mentioned (i.e package management) Wifi, WebKit, and the record, etc. also quite clearly show this)! Ask Stippi how many man unpaid man hours he's put into Package Management after the ~$20,000+ of open-ended contract dollars that were spent on it...

You don't know what you are writing about. I have not wrote a single line of code on Package Management. HaikuDepot is based on the new Package Management Kit. On all the hard work that Oliver and Ingo put into it. HaikuDepot has Package Management as its backend. It does nothing on itself.

kvdman wrote:

A good example was the Wifi Bounty with Axel Dörfler. The goals were established, yet Axel was unable to provide results. Axel later saying: "In the case of my bounty project, I ran out of time, and tried to make it work - that's stressful and unrewarding, and eventually led me to abandon work on that thing altogether. mmlr later debugged my work, and applied the one-liner that made it work."

Although, claiming the fix was a 'one-liner' debugged weeks later, the bounty and work together was 100% useless to the average user. Under pressure, I bowed to releasing the funds for Axel's work, but this shouldn't happen. The code could have stayed in the repository forever, useless to average users (like package management up until Stippi's alterations). Fortunately it was fixed by mmlr and the code was useable thereafter. But, lesson, learned, one must be firm and stick to established pre-determined contract goals. Otherwise, all the donated money would go to waste. It's not what the donors signed up for.

If there is any lesson to learn by that, it's that bounties are completely unfair when the hard work is not paid for because it doesn't reach the goal. Then someone can come along, track down a bug that can be fixed by a one-liner and collect the money instead of the developer having done all the hard work in the first place? You don't see a problem with that? I am glad the community pressured you into handing the bounty money to Axel.

Really, when you say Haiku Inc's conract projects are some sort of welfare, where developers chose to work on whatever they like and take as much time as they like, you have absolutely no idea.

Re: WebKit weekly report #50 - One year of WebKit!

Impressive. Keep up the good work.