Archive for the 'webkit' Category

Re: Debian Start

Adnan, for some reason, your post that is present on planet debian doesn't appear on your blog at the moment (Sorry, no posts matched your criteria.). I would have commented there if that were possible. Anyways, I will give my opinion here, with different hats on.

(User hat on) The idea to have a similar start page on the different browsers is a nice idea.

(Web designed hat on) Some implementation details on your mockup are discussable, most notably the design in pixels (which doesn't help for the vision impaired needing big fonts), the list of fonts to be used, and the border being part of the background image. Also, considering the targetted browsers, SVG could be a nice addition.

(Iceweasel, Xulrunner and WebKit maintainer hat on) The content at the bottom suggests the page is intended to be put online somewhere. Browsers start page shouldn't require an internet connexion.
There should also be space for browser-specific icon and text. I'd really like to keep specific links, such as to bug reports and README.Debian (though the latter should really be htmlized). Speaking of these links, another one should be added some day in the future, to provide a link to a page explaining how users can help the maintainers (thanks to whoever came up with this idea during my BoF at DebConf).

2009-08-25 20:24:42+0900

firefox, webkit, xulrunner | 5 Comments »

I’m weak

Not only have I not stopped working on WebKit, but I even touched the debian/copyright file :-/

Update: and now I even uploaded a new xulrunner package...

2009-03-27 22:52:22+0900

webkit, xulrunner | 2 Comments »

Orphaning packages

Since I am expected to spend more than half my packaging time updating the debian/copyright file, I am hereby orphaning nspr, nss, iceape and xulrunner. I am also stopping work on webkit and iceweasel, but they don't end up in the orphan state since they are comaintained.

Good luck to my fellow developpers. (And sorry, sincerely)

Update: As I do realize writing while being pissed doesn't help making the motives right, and apparently, some people have seen this as an extortion, let me make things clearer:

I was starting to work on xulrunner 1.9.1 when the discussion about the copyright files came up. It will require a significant amount of time, and while Noah Slater's opinion alone wouldn't really have carried me that far, despite me saying so because I got pissed by his words, 2 messages from Jörg Jaspert (the only ones he posted so far in the thread, by the way) did make it clear that my work on xulrunner 1.9.1 was going to be a waste of time, which I already lack to properly handle the bugs in my maintained packages, let alone keeping the copyright file up-to-date.

As I am obviously unable to handle the amount of work required to maintain big packages, as drawing new blood in the mozilla team has always failed so far, I just prefer to stop than to over-overflow. Call it extortion to get people in the mozilla team if you want, I'm fine with the notion.

I've been thinking to stop working on big packages for nearly a year already, but never mentionned it but to a few people in a few occasions. I couldn't resolve myself to do it, though I did reduce the amount of time I spend on these packages (I was overflown, a year ago). I just found an excuse to actually do it.

I must say I feel awkward now, and I still don't know if I will be able to keep this resolution.

As for the new copyright file format, with full licensing information and copyright holders list, I *did* try, on a significantly smaller piece of software than the mozilla packages, namely on Webkit, which is not really small either but still 6 times less files than xulrunner. I must say I hate to have to list copyright holders and file names with a passion, and the amount of time it takes. It is the main reason why there wasn't more uploads of WebKit svn snapshots in the archive...

Last but not least, thanks for the nice comments.

2009-03-21 18:54:03+0900

firefox, iceape, webkit, xulrunner | 16 Comments »

WebKit 1.1.3 in experimental

You may have noticed, or not, but WebKit 1.1.3, which has been released a few days ago, is available in experimental. The great news is that we now have a real maintenance team, because I now have a co-maintainer, who actually did most of the work getting the 1.1.x releases in shape for experimental.

Now, some JavaScript performance figures, as I have been doing for most WebKit releases I uploaded to the archive, with a recap of previous episodes:

All there tests have obviously been run on the same machine, under the same conditions. The machine in question is my x86-64 laptop, which means all these test are with a x86-64 binary.

This also means the last release, 1.1.3, doesn't take advantage of the Just In Time JavaScript compiler, which is only available on x86 binaries.

With the x86 binaries under a x86 personality chroot, I get under one second:

  • release 1.1.3, with JIT, x86: 985.4ms

But, in the last few days, I've been working on getting JIT first to build and then to work on x86-64 linux, and with the help of folks on the webkit-dev list, that just happened. And the result is just... wow.

  • release 1.1.3, with JIT, x86-64: 623.0ms

(Note that a few tests are actually slower than on x86)

That's so many times faster than what we had a year ago that it's almost unbelievable.

Expect the next upstream release, planned for some time in the near future, to have my patches applied. In the meanwhile, you can get them here and here.

2009-03-20 23:27:39+0900

webkit | Comments Off on WebKit 1.1.3 in experimental

webkit 1.0.1 in unstable

There has finally been an official webkit release for the Gtk+ port, and I finally took the necessary time to package it.

As you can guess from the screenshot above, it now has plugins support.

It is also über fast. You can compare with previous results for both gecko and webkit.

2008-07-06 15:52:43+0900

webkit | 3 Comments »

xulrunner++, webkit++

I uploaded xulrunner 1.9~b5-1 yesterday, and today was webkit's turn, with an upload of svn revision 31841, which happens to be the last revision on trunk as of writing.

Thanks to Mark Rowe, the most problematic crashers I experienced with webkit while preparing this upload have been fixed in revisions 31821 and 31787. This had the side effect to delay the upload enough that we now have the benefit of improved SVG animations support, and CSS gradients.

For those who like numbers, you can take a look at the Sunspider results for xulrunner 1.9~b5 (running mybrowser ; very similar results to what I got with 1.9~b4), and Sunspider results for webkit r31842 (when you compare to previous results for webkit r27674, there are significant improvements).

For another kind of numbers:

~/git/xulrunner$ git diff upstream/1.9... | filterdiff -x b/debian/* -x a/configure | diffstat | tail -1
36 files changed, 507 insertions(+), 291 deletions(-)

Compared to:
~/git/xulrunner$ git diff upstream/1.9...1.9+b4-1 | filterdiff -x b/debian/"*" -x a/configure | diffstat | tail -1
53 files changed, 932 insertions(+), 466 deletions(-)

~/git/webkit$ git diff upstream... | filterdiff -x b/debian/* | diffstat | tail -1
1 file changed, 4 deletions(-)

Compared to:
~/git/webkit$ git diff upstream...0+svn27674-4 | filterdiff -x b/debian/* | diffstat | tail -1
17 files changed, 61 insertions(+), 18 deletions(-)

Somehow, I prefer to work on webkit...

2008-04-12 23:24:20+0900

webkit, xulrunner | Comments Off on xulrunner++, webkit++

WebKit on the rocks

I'm preparing a new upload for WebKit, which will be targetted at unstable. It is much easier to deal with than Gecko, fortunately, so it won't take several months to get something in shape. The main "difficulties" here is that I'm dropping the Qt WebKit package, since this will be provided along Qt, and the upstream build system for the Gtk port switched from qmake to autotools, which is not a really bad thing ; so, nothing impossible.

Note that switching to autotools also means using libtool, which means no way to use -Wl,--as-needed anymore :-/. Yes, libtool, by trying to be smart, puts it almost at the last position in the arguments list, making it useless.

ACID3 in new GtkLauncher

2008-04-07 07:55:21+0900

webkit | 2 Comments »

Xulrunner 1.9beta4 *not* approaching experimental

I appear to have underestimated the remaining work needed to get xulrunner in a pleasant enough shape for an upload. Which means the package won't be ready this week-end. It's always when you come closer to the goal that it gets farther...

And I still haven't decided once and for all if I would still version the libxul library. The problem is the following: there are two different ways to link or load libxul: dependent glue or standalone glue. The first one dynamically links embedding applications to both libxpcom and libxul, while the second links to a static library (well, dynamic, in Debian, because there is no reason why we should need to binNMU all reverse dependencies whenever we fix something in the glue), which dlload()s libxul. From Mozilla POV, embedding applications are supposed to use the standalone glue.

Considering we will more than probably have both schemes in use within reverse dependencies, I'm not sure I still want to bother diverging from upstream by keeping SO versioning on libxpcom and libxul... That unfortunately means that we will go back to the previously sucky situation where reverse dependencies have to put a dependency on the Gecko runtime themselves. A debhelper might help, though.

I will keep SO versioning on libmozjs, though, because it has some reverse dependencies, and a changing ABI.

The good news, anyways, is that I was able to build and run Iceweasel on top of the xulrunner pre-package.

I also ran sunspider on both this Iceweasel 3.0b4 and Iceweasel 2.0 ; the difference is really impressive: 3.0b4 is almost 4 times as fast !

For reference, the Webkit currently in unstable (which is quite old, actually), gives these results. The one in experimental unfortunately crashes. By the way, I'm planning to package a new Webkit snapshot soon after I'm done with xulrunner and Iceweasel, we'll see then how it performs.

While speaking of tests, both Iceweasel 3.0b4 and Webkit from experimental pass the Acid 2 test (contrary to Iceweasel 2.0), and have both quite good results on the Acid 3 test: 61 for Webkit from experimental, when it doesn't crash (but current trunk has been reported to score 91 !), and 67 for Iceweasel 3.0b4 (compared to 52 for Iceweasel 2.0).

Update: Interestingly, built with upstream optimization flags (-Os-freorder-blocks -fno-reorder-functions) instead of -O2, it is slighly slower, though it might be better on some older hardware, or other architectures (I'm testing on x86-64).

2008-03-16 00:06:02+0900

webkit, xulrunner | 6 Comments »

WebKit and the Acid test

Someone in the "Why no Opera?" thread on the debian-devel list mentioned tkhtml/hv3, and how it passed the Acid Test (though he didn't mention if it was the first or the second Acid Test).

While it is a known fact that Mozilla doesn't pass the Second Acid Test yet (you have to use 1.9 alpha for this), it is also known that Safari has been for more than 2 years, and Konqueror, since version 3.5.2. So just to be sure, I gave it a try with WebKit (the one currently in unstable), and the results are... well, see for yourself.

This is what QtLauncher display, when the window is quite large, which is just perfect.
QtLauncher showing Second Acid Test

Now, this is what you get when the window is not so large, but still large enough for the whole thing to be displayed.
QtLauncher showing Second Acid Test #2

And what you get when you shrink the window more and more.
QtLauncher showing Second Acid Test #3 QtLauncher showing Second Acid Test #4

It goes further down when you shrink even more.

Sadly, the Gtk port is not as good.
GdkLauncher showing Second Acid Test

It also does the "going down when shrinking" thing.

Update : Apparently, the "going down when shrinking" thing is a known "feature" of the Acid Test.

Update : The reason why the Gtk port is not fully passing the test is that while there is a KIOslave for the data url scheme, curl doesn't support it.

2007-09-10 20:54:55+0900

webkit | 2 Comments »

Javascript performance in browsers

Ars Technica has recently posted an article about the new Opera alpha release, with some Javascript benchmark results showing it is quite faster than version 9.23. It also goes to compare with Firefox and IE7, but omits some other not so unimportant browsers. I think the main reason is because they seem to have only tested Windows browsers. Sure, Safari has been released recently on Windows, but it is still quite marginal.

Anyways, I was wondering how all this was going under Linux, and also, how (good?) WebKit would perform compared to others.

So, I tried the same Javascript speed tests on various browsers under Linux on my laptop, which happens to be a Pentium M 1.5GHz.

And the winner is...

Test Iceweasel 2.0.0.6 Epiphany 2.18.3/libxul 1.8.1.6 GdkWebKit Opera 9.23 Opera 9.50 alpha 1
Try/Catch with errors 80 81 41 18 22
Layer movement 250 214 76 53 47
Random number engine 280 190 57 72 68
Math engine 343 274 82 101 91
DOM speed 205 225 18 41 54
Array functions 97 97 72 82 44
String functions 14 12 12 46 52
Ajax declaration 178 127 16 21 17
Total 1447 1220 374 434 395

So, It seems the speed gain Opera got on Windows doesn't happen much on Linux.

An interesting result, is that Iceweasel, with a bunch of extensions installed, is slower than Epiphany, despite both using the same rendering engine and Javascript library. Running Iceweasel in safe mode makes it the same speed as Epiphany, though. So having extensions does not only clutter the UI, but actually has an impact on how fast the Javascript code in web pages is going to run.

And well, WebKit is the fastest for this testcase, though it stays behind Opera on some specific tests.

2007-09-07 21:44:19+0900

firefox, iceape, webkit, xulrunner | 2 Comments »