Planet WebKit

Cameron Zwarich is a WebKit Reviewer

2008-06-23T20:58:10+00:00

Cameron Zwarich is now a qualified WebKit Reviewer. Cameron has been doing amazing work on the JavaScript implementation and was one of the core developers on the new bytecode engine. He has also branched out into other areas of the code and squashed bugs of all varieties. Please join me in congratulating Cameron on his reviewer status and thanking him for all of his contributions to WebKit.

The cost of a bug fix

2008-06-12T19:41:59+00:00

Every fix doesn’t call for a blog post, but this one deserves it. It all started when Jonathon Jongsma found a way to make text disappear in QtWebKit on May 27th. So he raised a bug. He and I started working on fixing it. We rapidly found that WebKitGtk was also affected, but it was unreproducible on the Mac port.

We dove into the code: “grep selection”, GraphicsContext::drawText(), Font::drawText()… but nothing was really different (there) in the Qt or Gtk port which could explain why the text wasn’t being redrawn when changing the selection.

That’s when I discovered git bisect. Since we had established that the bug wasn’t there when QtWebKit was snapshot for Qt 4.4.0, I had a good place to start. So after recompiling QtWebKit some 15 times (yes, it took around 3 work days!), it pointed me to this changeset. Lucky for us, it was related to the bug (text rendering).

After some digging into the patch, I contacted the author, Dan Bernstein at Apple, and we looked at it together. In little time, he was able to find how to reproduce it on the Mac too. This was now a WebKit wide bug! Some back traces later and some trials: we came up with this fix. Pretty simple, isn’t it? barely 16 chars. Yet, these 16 chars cost around 1200$* in direct labour time and 3 engineers were involved.

Some will say this could have been prevented with proper tests. It happens that it was a special case on the Mac, but all other ports always went through it. Dan now added a pixel test.

The morals of the story are:

bug fixing is costly (haven’t we heard that in school?)
you never know when someone will hunt you back about your patch
git is a cool beast (in fact, it just convinced me to use it)

One question lasts: how come it took over a month and a half before someone found it?

* This number is based on market mean hourly rate since exact rates are unknown

Side note on the WebKit party

It was really cool to get to San Francisco and finally meet IRL other WebKit devs. Kudos for the event!

WebKit Meta: A new standard for in-game web content

2008-06-12T09:35:20+00:00

Over the last few months, our browser team at Nuanti Ltd. has been developing Meta, a brand new WebKit port suited to embedding in OpenGL and 3D applications. The work is being driven by Linden Lab, who are eagerly investigating WebKit for use in Second Life.

While producing Meta we’ve paid great attention to resolving the technical and practical limitations encountered with other web content engines.

uBrowser running with the WebKit Meta engine

High performance, low resource usage

Meta is built around WebKit, the same engine used in web browsers like Safari and Epiphany, and features some of the fastest content rendering around as well as nippy JavaScript execution with the state of the art SquirrelFish VM. The JavaScript SDK is available independently of the web renderer for sandboxed client-side game scripting and automation.

It’s also highly scalable. Some applications may need only a single browser context but virtual worlds often need to support hundreds of web views or more, each with active content. To optimize for this use case, we’ve cut down resource usage to an absolute minimum and tuned performance across the board.

Stable, easy to use cross-platform SDK

Meta features a single, rock-solid API that works identically on all supported platforms including Windows, OS X and Linux. The SDK is tailored specifically to embedding and allows tight integration (shared main loop or operation in a separate rendering thread, for example) and hooks to permit seamless visual integration and extension. There is no global setup or initialization and the number of views can be adjusted dynamically to meet resource constraints.

Minimal dependencies

Meta doesn’t need to use a conventional UI toolkit and doesn’t need any access to the underlying windowing system or the user’s filesystem to do its job, so we’ve done away with these concepts almost entirely. It adds only a few megabytes to the overall redistributable application’s installed footprint and won’t interfere with any pre-installed web browsers on the user’s machine.

Open Source, no licensing fees

In the short term, we’ll be maintaining Meta in a public branch and putting out SDK builds, demo applications and developer documentation. Nuanti will be offering commercial and community support and is anticipating involvement from the gaming industry and homebrew programmers.

In the mid term, we’ll submit Meta as an official component of the WebKit Open Source project, where our developers are already actively involved in maintaining various subsystems.

Find out more

Today we’re launching meta.nuanti.com and two mailing lists to get developers talking. We’re looking to make this site a focal point for embedders, choc-full of technical details, code samples and other resources.

Qt Jambi 4.4.0 Released!

2008-06-10T09:13:27+00:00

So the time is finally here. Qt 4.4.0 was released a few weeks ago and as promised Qt Jambi is right behind. A lot of effort has gone into this one, in addition to supporting all the new Qt features, like Phonon, Webkit, Widgets in Graphics View, XQuery and Qt Concurrent, we also have a seriously improved deployment system, JDBC support and a compile-time checked signal-slot approach for the paranoid. Its a good time to be a Java developer I tell yah! We already mentioned all the featuers in the Qt Jambi 4.4.0 Preview Blog so we won’t repeat ourselves here… (There is a danger in linking to eskils blog, as it links to others again, which again links to others, which in the end proves to be a fairly complex graph, but then again… we are engineers and like that kind of stuff)

Under the cover we’ve also done quite some work. We also did an overhaul of the garbage collection and memory management subsystem and hopefully ironed out all the bumps and dents. We’ve also done some work on the build system, so that our users that build from source have a bit more substantial buildsystem to work with. Previously it was a complex install document, which has been replaced by a simple ant command which just does it all… I was very happy to see that the deployment system & ANT build scripts works well enough for the webstart to look like a plain, normal webstart app:

<resources> <j2se version="1.5+"/> <jar href="qtjambi-examples-4.4.0_01.jar"/> <jar href="qtjambi-4.4.0_01.jar"/> </resources>

No magic nativejar or anything like that, just the qtjambi-win32-msvc2005-4.4.0_01.jar in the classpath and that is enough to load it, jpeg and svg plugins and all. The good thing is that the files included in the webstart are produced directly by the ant script with all dependencies etc set up properly… (well… almost properly, it took us an evening last week to get it really working, but now it works properly). Because of the fixes to memory management and deployment Eskil and I got these offical diplomas:

So, what more is there to say… Try the webstart with its new demos, download the packages and start hacking!

-
The Qt Jambi Team

Announcing SquirrelFish

2008-06-03T01:37:06+00:00

“Hello, Internet!”

WebKit’s core JavaScript engine just got a new interpreter, code-named SquirrelFish.

SquirrelFish is fast—much faster than WebKit’s previous interpreter. Check out the numbers. On the SunSpider JavaScript benchmark, SquirrelFish is 1.6 times faster than WebKit’s previous interpreter.

SunSpider runs per minute

Longer bars are better.

What Is SquirrelFish?

SquirrelFish is a register-based, direct-threaded, high-level bytecode engine, with a sliding register window calling convention. It lazily generates bytecodes from a syntax tree, using a simple one-pass compiler with built-in copy propagation.

SquirrelFish owes a lot of its design to some of the latest research in the field of efficient virtual machines, including research done by Professor M. Anton Ertl, et al, Professor David Gregg, et al, and the developers of the Lua programming language.

Some great introductory reading on these topics includes:

The Structure and Performance of Efficient Interpreters (Introduces the fundamentals of virtual machine design and explains the importance of direct threading)
Virtual Machine Showdown: Stack Versus Registers (Details the benefits of register machines, and the importance of copy propagation)
The Implementation of Lua 5.0 (Outlines the implementation of a real-world register-based bytecode engine, with a sliding register window calling convention)

I’ve also pored over stacks of terrible books and papers on these topics. I’ll spare you those.

Why It’s Fast

Like the interpreters for many scripting languages, WebKit’s previous JavaScript interpreter was a simple syntax tree walker. To execute a program, it would first parse the program into a tree of statements and expressions. For example, the expression “x + y” might parse to

        +
      /   \
     x     y

Having created a syntax tree, the interpreter would recursively visit the nodes in the tree, performing their operations and propagating execution state. This execution model incurred a few types of run-time cost.

First, a syntax tree describes a program’s grammatical structure, not the operations needed to execute it. Therefore, during execution, the interpreter would repeatedly visit nodes that did no useful work. For example, for the block “{ x++; }”, the interpreter would first visit the block node “{…}”, which did nothing, and then visit its first child, the increment node “x++”, which incremented x.

Second, even nodes that did useful work were expensive to visit. Each visit required a virtual function call and return, which meant a couple of indirect memory reads to retrieve the function being called, and two indirect branches—one for the call, and one for the return. On modern hardware, “indirect” is a synonym for “slow”, since indirection tends to defeat caching and branch prediction.

Third, to propagate execution state between nodes, the interpreter had to pass around a bunch of data. For example, when processing a subtree involving a local variable, the interpreter would copy the variable’s value between all the nodes in the subtree. So, starting at the “x” part of the expression “f((x) + 1)”, a variable node “x” would return x to a parentheses node “(x)”, which would return x to a plus node “(x) + 1”. Then, the plus node would return (x) + 1 to an argument list node “((x) + 1)”, which would copy that value into an argument list object, which, in turn, it would pass to the function node for f. Sheesh!

In our first rounds of optimization, we squeezed out as much performance as we could without changing this underlying architecture. Doing so allowed us to regression test each optimization we wrote. It also set a very high bar for any replacement technology. Finally, having realized the full potential of the syntax tree architecture, we switched to bytecode.

SquirrelFish’s bytecode engine elegantly eliminates almost all of the overhead of a tree-walking interpreter. First, a bytecode stream exactly describes the operations needed to execute a program. Compiling to bytecode implicitly strips away irrelevant grammatical structure. Second, a bytecode dispatch is a single direct memory read, followed by a single indirect branch. Therefore, executing a bytecode instruction is much faster than visiting a syntax tree node. Third, with the syntax tree gone, the interpreter no longer needs to propagate execution state between syntax tree nodes.

The bytecode’s register representation and calling convention work together to produce other speedups, as well. For example, jumping to the first instruction in a JavaScript function, which used to require two C++ function calls, one of them virtual, now requires just a single bytecode dispatch. At the same time, the bytecode compiler, which knows how to strip away many forms of intermediate copying, can often arrange to pass arguments to a JavaScript function without any copying.

Just the Beginning

In a typical compiler, conversion to bytecode is just a means to an end, not an end in itself. The purpose of the conversion is to “lower” an abstract tree of grammatical constructs to a concrete vector of execution primitives, the latter form being more amenable to well-known optimization techniques.

Therefore, though we’re very happy with SquirrelFish’s current performance, we also believe that it’s just the beginning. Some of the compile-time optimizations we’re looking at, now that we have a bytecode representation, include:

constant folding
more aggressive copy propagation
type inference—both exact and speculative
specialization based on expression context—especially void and boolean context
peephole optimization
escape analysis

This is an interesting problem space. Since many scripts on the web are executed once and then thrown away, we need to invent versions of these optimizations that are simple and efficient. Moreover, since JavaScript is such a dynamic language, we also need to invent versions of these optimizations that are resilient in the context of an unknown environment.

We’re also looking at further optimizing the virtual machine, including:

constant pool instructions
superinstructions
instructions with implicit register operands
advanced dispatch techniques, like instruction duplication and context threading
getting computed goto working on Windows

Performance on Windows has extra room to grow because the interpreter on Windows is not direct-threaded yet. In place of computed goto, it uses a switch statement inside a loop.

Getting Involved

If you’re interested in compilers or virtual machines, this is a great project to join. We’re moving quickly, so the best way to come up to speed is to log on to our IRC channel.

As always, testing out nightly builds and reporting bugs is also a great help.

Extra Bonus Updates

We’ve got some extra bonus info: very early draft documentation of the SquirrelFish VM’s opcodes. For those of you who know about VMs, you may find this enlightening, for those who don’t, you may find it is simpler than you expect.

In addition, we have a detailed comparison of Safari 3.1 vs. SquirrelFish, looking at the individual tests, it is interesting to see which sped up the most. If you look at this comparison to Safari 3.0, you can see that we’ve sped up 4.34x overall since Safari 3, and have improved some kinds of code by over an order of magnitude.

SquirrelFish around the web: There’s lots of interesting discussion in the reddit article about this post. And posts from key SquirrelFish developer Cameron Zwarich has performance data and other info, as does occasional WebKit contributor Charles Ying.

SquirrelFish has landed!

2008-06-02T23:35:21+00:00

Hey, everybody. I’m a Google Summer of Code student this year, working on performance improvements for JavaScriptCore, WebKit’s JavaScript interpreter. The official WebKit blog just announced SquirrelFish, our incremental rewrite of JavaScriptCore. In just about two months, we went from an AST-based interpreter to an optimized bytecode interpreter, achieving a substantial performance improvement in the process. Ever since it landed, people have been asking for comparisons between bleeding edge versions of the leading browsers, so here are some SunSpider numbers:

WebKit r34318:	2248.0 ms
Firefox 3.0 RC1:	3288.0 ms
Opera Snapshot 4844:	6012.2 ms

This means that WebKit is 1.46 times faster than Firefox, and 2.67 times faster than Opera. The machine I used for testing is a 2.16 GHz Core 2 Duo MacBook Pro running Mac OS X 10.5.3.

The development process was a real blast. I got a chance to work with some great programmers while improving software that is widely used. There isn’t much more that one can ask for in the world of open source, or software development in general. We really worked well as a team, helping one other with writing patches, code review, running performance tests, and just giving general encouragement. I was finishing my master's thesis at the same time, so there wasn’t a dull moment in my life.

Much of this work was done before the accepted students for Summer of Code were announced, and the SquirrelFish branch merged a few days before the program officially started, so I think I’ve been doing a pretty good job on my project so far. Since the merge, we have been brainstorming further performance improvements, and we are getting to work on implementing them. I'll try to post about some of the things we do on this blog from time to time.

Bringing Web Inspector to Linux

2008-06-02T08:09:24+00:00

For web developers, when it comes to debugging the web applications, tools like Firebug for Firefox, Safari Web Inspector and the recently introduced Opera Dragonfly can be handy and very useful. These kinds of tools offers the possibility to trace the DOM, verify the corresponding (computed) CSS, check network usage and resource loading performance, debug JavaScript, etc.

As for the Web Inspector (which is technically a WebKit feature), it is written in HTML/CSS/JavaScript except for the rather small platform-specific InspectorClient code. As Holger has mentioned before, with QtWebKit it is very easy to bring WebInspector into any QtWebKit-based browser, such as the Demo Browser (shipped with Qt 4.4) or its successor Arora. Since these browsers are available on several platforms, it also means now you can use Web Inspector on Linux (*). Using either the Demo Browser or Arora, just open the menu Tools, Enable Web Inspector and you are ready. After loading any web site, right click on the web page to find the menu item Inspect that will launch the Web Inspector.

The screenshot below gives the unsurprising proof of Web Inspector on Linux (click to enlarge):

In the example, I was trying to find out the potential slow-down in SpeedCrunch website. It was easy to spot that the Slideshow JavaScript (slideshow.js) takes around 200 ms. If this particular JavaScript code can be deferred, the web page would have been 200 ms faster.

What about other WebKit-based application? If your application is using QtWebKit, it is almost trivial to enable the Web Inspector. You can use the action available from QWebView::pageAction or trigger it directly using QWebView::triggerPageAction, in both cases passing QWebPage::InspectElement as the action. Easy enough, isn’t it?

Happy inspecting!

(*) Before, it is only possible if you run Safari under Wine

Safari Hits 6.25% Market Share

2008-06-01T05:04:52+00:00

The latest browser market share data is in, and Safari has hit 6.25%, breaking 6% for the first time. Last month’s share was 5.81%, so this is a significant increase. It was only nine months ago that Safari broke 5%. Safari market share has now almost tripled from 2.14% in June 2005, when the WebKit Open Source project launched.

This growth, combined with recent WebKit adoption in projects such as the Iris Browser, Qt 4.4, Android, Adobe AIR, Epiphany, KDE Plasma, iCab and more, is breathtaking and shows huge positive momentum for the WebKit project. Thanks and congratulations to everyone who has contributed to the project.

Third Annual WebKit Open Source Party

2008-05-28T19:08:10+00:00

It’s that time of year again! Web developers, WebKit hackers, browser developers, or anyone with an interest in cool technology should come have a drink and some snacks, and meet WebKit contributors from Apple and around the world. This event is open to anyone who is interested, free of charge.

Don’t miss out on the nerd party of the century!!!!

Details

Place: Thirsty Bear Restaurant & Brewery (map)
Date: Tuesday, June 10th
Time: 7:30 PM
upcoming.org

Bit Rot

2008-05-28T14:43:45+00:00

After a nearly two-month self-imposed death march in "the real world", I've gotten back to my WebKit hacking. As expected, several aspects of the build process were broken, but it was exciting to see the massive progress on almost all fronts.

First, daddy-o Hyatt managed to get CSS gradients working nicely, and I'm pleased to report that this came through in the Cairo build flawlessly:

Second, Dave implemented shadows for fonts, which also works properly:

Finally, image reflection is working:

It's really amazing how much functionality is present in a modern web engine, and that so much of it works without having to do much under the Cairo-backed Windows build.

To recreate this build on your own (and I hope you do so we can verify everything is getting properly committed to the archive) you will have to add a few pending patches to the WebKit SVN source tree.:

As before, you will need to add 17730 to get cURL support, as well as some odds-and-ends in 17484

You may still want to extend build-webkit with the --cairo flag, as coded in 17952.

Top Secret, Hush Hush!

2008-05-13T13:31:02+00:00

So, after Simon snitched on me and leaked highly sensitive information about my top-secret project, I guess it’s finally time to spill the beans.

Yes, it is true. For the past few months I have been semi-secretly working on ~~taking over the world~~ implementing support for the HTML5 video and audio elements in the Qt port of WebKit, using Phonon as the media backend. This adds QtWebKit to the list of cool browsers that support this feature.

The introduction of a special purpose media element in the HTML5 draft allows embedding of audio and video content into web pages without resorting to using the generic object tag with some random plugin-based player. It’s as easy as this:

<video src="foobar.ogg">Fallback content here.</video>

The media element also comes with a scripting API, making it easy to roll your own player interface if you want to (or use the default one provided by the user agent by adding the controls attribute).

Employing Phonon to implement the playback started out as my “hey-welcome-to-Trolltech-here-is-a-fun-task-for-you”-project, but turned out to also be a good test-case for the implementation of the various Phonon backends we are doing here at Trolltech. The project was momentarily put on ice while we were busy stabilizing the 4.4 release, but now that 4.4 is out the door it’s time to get back in the saddle.

Some of the tasks currently in the pipeline are Win and Mac support (which is still largely untested), full screen support using overlays (for speed), routing the data through an IODevice rather than just passing a URL (which will help buffering and let us ensure that per-site credentials will work), plus implementing more of the default UI controls.

Initial support is already in WebKit trunk for those of you who want to try it out, and the finished result will be in Qt 4.5. Here’s a screenshot, for you pixel peepers out there:

QtWebKit Development Update

2008-05-09T13:44:01+00:00

As part of Qt 4.4 we have now made our very first release!

Shortly before the release we finished merging all our changes back to the Subversion trunk branch, where we are working directly now. We will continue to maintain and bugfix the code in the Qt 4.4.x release series, but we try to make the changes in trunk first and then backport changes as they fit.

Our current goal is to catch up with the architectural changes that happened in trunk and maintain the layout tests. Holger for example fixed the HTML Canvas after some internal API changes. Ariya started working on Netscape plugins for Windows and Tor Arne I heard is polishing a secret feature he’s been semi-secretly working on for a while now in not-so-secret trunk. I heard rumors that he’s going to secretly blog about the secret feature soon, so stay tuned.

Big props also to Marc and the guys at Collabora for landing the initial support for Netscape plugins for the X11 Qt and Gtk ports in WebKit trunk! Great job!

On the application side Urs Wolfer’s Google Summer of Code project for integrating QtWebKit into KDE has been accepted. Congrats Urs! Feel free to stop by in #webkit and bug us if you have questions

Reporting WebKit Security Bugs

2008-05-08T02:22:23+00:00

Security is a top priority for the WebKit project. As contributors to the project have grown, it has become apparent that we need a process for safely reporting security vulnerabilities to the WebKit project in addition to the process for reporting vulnerabilities to Apple. Today, we are announcing a new mailing list for this purpose, security@webkit.org. In addition, you can now safely report vulnerabilities over https to our bug tracker, https://bugs.webkit.org, by placing the bug in the Security component. The people privy to the mailing list and the Security component are members of the Security group. It currently includes vendors shipping products that include WebKit, active port owners and trusted security experts. If you are shipping a product that includes WebKit and would like to be notified of security issues, please email security@webkit.org.

CSS Reflections

2008-04-29T21:07:33+00:00

WebKit now supports reflections in CSS. Continuing the trend of using adorable baby photos to make features appear more impressive, let me introduce Kate again.

A reflection is a replica of the original object with its own specific transform and mask. The box-reflect property can be used to specify the specialized transform and mask that should be used for the replica.

-webkit-box-reflect: <direction> <offset> <mask-box-image>

<direction> can be one of above, below, left or right.
<offset> is a length or percentage that specifies the distance of the reflection from the edge of the original border box (using the direction specified). It can be omitted, in which case it defaults to 0.
<mask-box-image> is a mask-box-image that can be used to overlay the reflection. If omitted, the reflection has no mask.

Reflections will update automatically as the source changes. If you hover over links, you’ll see the hover effect happen in the reflection. If you reflect the <video> element, you will see the video playing in the reflection.

Giving an element a reflection has the effect of creating a stacking context (so it joins opacity, masks and transforms). The reflection is non-interactive, so from the point of view of hit testing, it’s like it isn’t there. The reflection will have no effect on layout (other than being part of a container’s overflow), and can be thought of as similar to box-shadow in this respect.

The example above uses a gradient mask. Here is the sample code:

<img src=”bubbles.jpg” style=”border:5px solid white;-webkit-box-reflect:below 5px -webkit-gradient(linear, left top, left bottom, from(transparent), color-stop(0.5, transparent), to(white));”>

Arora & QtWebKit Trunk

2008-04-28T11:15:45+00:00

Arora

The demo browser in Qt 4.4 has obtained a lot of attention and interest. Now that 4.4 is almost out I have forked it and started a new project called Arora where development can continue, features can be added, and anyone who wants can contribute. The source code is in a Git repository and is currently hosted on github. Along with some improvements and features there are autotest and manual tests. Git (and GitHub) makes it pretty easy for new developers to a project to fork off a branch to develop features that can be later merged back into the project. Feel free to grab the source and add the feature that you miss the most or take one of the fun items off the TODO list. To any artists out there we need an icon to match the new name. Given that this is a fork of the demo future news on Arora will be on the project’s home page or on the Arora blog.

QtWebKit & WebKit trunk

In an effort to stabilize QtWebKit before the 4.4 release QtWebKit was forked from WebKit about six months ago. This is why the acid3 test score in Qt4.4 didn’t match the latest Safari. Now that 4.4 is almost out the door work has begun on integrating the changes into WebKit trunk for 4.5. Not everything is in yet, but already a lot works and it is very exciting. I’ll let this screen shot speak for itself:

The remaining failing tests mostly relate to SVG Fonts. If you are interested in helping out feel free to join #webkit or #qtwebkit on freenode. Instructions on how to build Arora with QtWebKit trunk can be found in the Arora source wiki page.

CSS Masks

2008-04-24T19:53:46+00:00

WebKit now supports alpha masks in CSS. Masks allow you to overlay the content of a box with a pattern that can be used to knock out portions of that box in the final display. In other words, you can clip to complex shapes based off the alpha of an image.

Here is a snapshot of the Speed Racer movie trailer clipped to the Safari compass icon. This is in fact a mask applied to the <video> element.

We have introduced new properties to provide Web designers with a lot of control over these masks and how they are applied. The new properties are analogous to the background and border-image properties that already exist.

-webkit-mask (background)
-webkit-mask-attachment (background-attachment)
-webkit-mask-clip (background-clip)
-webkit-mask-origin (background-origin)
-webkit-mask-image (background-image)
-webkit-mask-repeat (background-repeat)
-webkit-mask-composite (background-composite)
-webkit-mask-box-image (border-image)

Use of a mask results in a stacking context being created (similar to how opacity and transforms work). The mask will therefore overlay the child and all of its descendants, and at a minimum will knock out everything outside the border box of the object.

From a Web designer’s perspective, think of the mask as being constructed the way the backgrounds and border-image of a box are constructed. Multiple backgrounds are stacking on top of one another (possibly overlapping) with their own tiling and clipping rules. A border-image can then potentially be stretched or tiled over the backgrounds.

The final resultant image built from putting all of the mask images together, tiling them, stretching them, etc., then becomes the mask used to clip the content. Alpha values of 0 in the mask mean that nothing should be drawn. Alpha values of 1 mean the content should display normally. Anything in between ends up partially transparent.

One key difference between mask-box-image and its border-image counterpart is that it doesn’t attempt to fit itself to border widths. It will just render the corners unscaled and tile/stretch itself into the border box without regard for the border itself. This lets you easily use nine-piece-image effects as masks on elements without borders (often image or video elements).

Here are two sample images. The source image that we want to mask and then the image that we will use as the mask.

We can place a mask on the image element simply by doing this:

<img src=”kate.png” style=”-webkit-mask-box-image: url(mask.png) 75 stretch;”>

The result looks like this:

CSS gradients can be used as the mask image source as well. In the following example a linear gradient is used to achieve a fade effect. For example:

<img src=”kate.png” style=”-webkit-mask-image: -webkit-gradient(linear, left top, left bottom, from(rgba(0,0,0,1), to(rgba(0,0,0,0))”>

Masks respect the border-radius curves of an object. We can add a border-radius to the previous example, and have both the gradient fade effect with rounded corners.

<img src=”kate.png” style=”-webkit-border-radius: 10px; -webkit-mask-image: -webkit-gradient(linear, left top, left bottom, from(rgba(0,0,0,1), to(rgba(0,0,0,0))”>

SVG images can be used as masks. For example, a partially transparent circle:

can be applied as a mask like so:

<img src=”kate.png” style=”-webkit-mask-image: url(circle.svg)”>

The end result is shown below:

All of the power of the multiple background and border-image syntax is at your disposal when building masks!

As usual leave feedback in the comments and file bugs on any problems you notice at http://bugs.webkit.org/.

WebKit GSoC Students Announced

2008-04-21T20:10:59+00:00

Google has released the list of students they will be sponsoring to work on WebKit as part of the Google Summer of Code this year. Congratulations to all of the students. We look forward to working with you closely this summer!

Thank you again to all the great students who applied! Unfortunately we had over twice as many applications as we had funding slots from Google. You’re certainly all welcome to come hack with us in #webkit any time.

Google’s official announcement

Acid3 final touches

2008-04-21T02:38:37+00:00

Recently we’ve been working to finish off and land the last couple of fixes to get a perfect pixel-for-pixel match against the reference Acid3 rendering in WebKit/GTK+. I believe we’re the first project to achieve this on Linux — congratulations to everyone on the team!

Epiphany using WebKit r32284

We also recently announced our plans to align more closely with the GNOME desktop and mobile platform. To this end we’re making a few technology and organisational changes that I hope to discuss in an upcoming post.

CSS Canvas Drawing

2008-04-17T19:33:40+00:00

Currently the set of images you can use from CSS consists of the following:

Bitmap Images (PNG, GIF, JPG)
SVG Images
Gradients

A notable missing ability when compared with explicit DOM content is programmatic drawing into CSS images. The <canvas> element represents a foreground bitmap image that can be drawn into programmatically, but - aside from inefficient hacks involving toDataURL - there hasn’t been any way to draw into the image buffers used by CSS images.

Until now!

In the latest nightlies, you can try out a new feature: the ability to specify named image buffers in CSS and then to draw into them programmatically from JavaScript. Here’s how it works.

background: -webkit-canvas(mycanvas);

Instead of specifying an image URL, you specify a canvas and an identifier to use for that canvas. The following new API on documents can then be used to obtain a drawing context for that canvas.

CanvasRenderingContext getCSSCanvasContext(in DOMString contextType, in DOMString identifier, in long width, in long height);

There is only one CSS canvas for a given global identifier per document. When you obtain the drawing context you also specify the size. The canvas will not be cleared as long as you repeatedly request the same size. Specifying a new size is equivalent to the kind of behavior you’d expect if you resized a <canvas> element, and so the canvas buffer will be cleared.

All objects that observe a CSS canvas of the same name are sharing that canvas. This means that (similar to how animated GIFs work), you can do animations and have them happen in lockstep on all the clients of the canvas. Drawing changes will be propagated to all clients automatically.

Here is an example:

Canvas as Background Image

Introducing CSS Gradients

2008-04-14T20:39:49+00:00

WebKit now supports gradients specified in CSS. There are two types of gradients: linear gradients and radial gradients.

The syntax is as follows:

-webkit-gradient(<type>, <point> [, <radius>]?, <point> [, <radius>]? [, <stop>]*)

The type of a gradient is either linear or radial.

A point is a pair of space-separated values. The syntax supports numbers, percentages or the keywords top, bottom, left and right for point values.

A radius is a number and may only be specified when the gradient type is radial.

A stop is a function, color-stop, that takes two arguments, the stop value (either a percentage or a number between 0 and 1.0), and a color (any valid CSS color). In addition the shorthand functions from and to are supported. These functions only require a color argument and are equivalent to color-stop(0, …) and color-stop(1.0, …) respectively.

Paraphrasing the HTML5 spec and adjusting the language slightly to not be canvas-specific:

“The color of the gradient at each stop is the color specified for that stop. Between each such stop, the colors and the alpha component must be linearly interpolated over the RGBA space without premultiplying the alpha value to find the color to use at that offset. Before the first stop, the color must be the color of the first stop. After the last stop, the color must be the color of the last stop. When there are no stops, the gradient is transparent black.

…

If multiple stops are added at the same offset on a gradient, they must be placed in the order added, with the first one closest to the start of the gradient, and each subsequent one infinitesimally further along towards the end point (in effect causing all but the first and last stop added at each point to be ignored).”

The points of a linear gradient specify a line. Linear gradients must be rendered such that at and before the starting point the color at offset 0 is used, that at and after the ending point the color at offset 1 is used, and that all points on a line perpendicular to the line that crosses the start and end points have the color at the point where those two lines cross (with the colors coming from the interpolation described above).

If x0 = x1 and y0 = y1, then the linear gradient must paint nothing.

For a radial gradient, the first two arguments represent a start circle with origin (x0, y0) and radius r0, and the next two arguments represent an end circle with origin (x1, y1) and radius r1.

Radial gradients must be rendered by following these steps:

If x0 = x1 and y0 = y1 and r0 = r1, then the radial gradient must paint nothing. Abort these steps.

Let x(ω) = (x1-x0)ω + x0

Let y(ω) = (y1-y0)ω + y0

Let r(ω) = (r1-r0)ω + r0

Let the color at ω be the color of the gradient at offset 0.0 for all values of ω less than 0.0, the color at offset 1.0 for all values of ω greater than 1.0, and the color at the given offset for values of ω in the range 0.0 ≤ ω ≤ 1.0

For all values of ω where r(ω) > 0, starting with the value of ω nearest to positive infinity and ending with the value of ω nearest to negative infinity, draw the circumference of the circle with radius r(ω) at position (x(ω), y(ω)), with the color at ω, but only painting on the parts of the surface that have not yet been painted on by earlier circles in this step for this rendering of the gradient.

This effectively creates a cone, touched by the two circles defined in the creation of the gradient, with the part of the cone before the start circle (0.0) using the color of the first offset, the part of the cone after the end circle (1.0) using the color of the last offset, and areas outside the cone untouched by the gradient (transparent black).”

So what exactly is a gradient in CSS? It is an image, usable anywhere that image URLs were used before. That’s right… anywhere.

You can use gradients in the following places:

background-image
border-image
list-style-image
content property

Gradients as Backgrounds

When specifying a gradient as a background, the gradient becomes a background tile. If no size is specified, then the gradient will size to the box specified by the background-origin CSS3 property. This value defaults to padding, so you the gradient will be as large as the padding-box. This is equivalent to a specified background-size of 100% in both directions.

If you want to achieve effects like tiling of a vertical gradient using a narrow strip, you should specify background-size to give the gradient tile an explicit size.

Gradients used as backgrounds will respect full page zoom, acquiring sharper resolution as the page is zoomed in.

Background Gradients Example

Border Image Gradients

Gradients can be used as border images. The most sensible use for them is specifying only horizontal or only vertical borders (and splitting the gradients up between the top and bottom or left and right borders).

The size of the gradient image is always the size of the border box.

Border Image Gradient Example

List Bullet Gradients

Gradients can be specified as list bullets. One problem with list bullet gradients is that there is currently no way in WebKit to specify the size of the marker box. Therefore the size of the image cannot be specified. WebKit has therefore chosen a default size based off the current font size of the list item.

List Item Gradients Example

Generated Content Gradients

Gradients can be used inside the content property. The image will fill the available width and height of its containing block. Therefore when using gradients inside ::before and ::after content with a specified size, it is important to set the display type to block or inline-block.

Gradients can also be used to do image replacement, so can be used with the img element in HTML or to replace the contents of other elements like spans and divs.

Generated Content Gradients Example

Final Notes

WebKit now supports a generic architecture for generated images, making it easy to add new generator effects to CSS in the future (lenticular halos, checkerboards, starbursts, etc.). The rules for sizing of these generated images will match whatever is decided for SVG content with no intrinsic size (the two are sharing the same rules right now).

We encourage you to try gradients out and file bugs if you see any unexpected or weird behavior. They will degrade safely in other browsers as long as you use multiple declarations (e.g., specify the image in one declaration and the gradient in a following declaration).

Summer of Code projects for browser hackers

2008-04-06T20:40:39+00:00

With the revised deadline for Google Summer of Code ‘08 student applications looming, we’ve been getting a lot of interest in browser-related student projects. I’ve put together a list of some of my favourite ideas.

GNOME ideas
- Epiphany
  - Desktop integration
  - Bookmark and history integration
  - JavaScript debugger based on Drosera / Web Inspector
- Evolution
  - Bug tracking aid
- Empathy
  - WebKit Adium theme support
- Desktop widgets
- Integrated web app launcher
WebKit ideas
- Cairo SVG backend completion
- GTK+ port test suite completion
Mono ideas
- WebKit-based HTML editor

If in doubt, now’s the time to submit proposals. Already-listed ideas are the most likely to get mentored but students are free to propose their own ideas as well. Proposals for incremental improvements will tend to be favoured over ideas for completely new applications, but a proof of concept and/or roadmap can help when submitting plans for larger projects.

Update: There’s no need to keep asking about the status of an application on IRC/private mail etc. It’s a busy time for the upstream developers but they’ll get back in touch as soon as possible.

cURL, Grokking those URL's

2008-04-03T18:42:15+00:00

With help from Daniel Zucker at Wake3.com, the wxWindows and GTK+ teams, and the folks on #webkit we've finally got a building version of WebKit that does not rely on CFNetwork. Instead, it uses the same cURL backend as wxWindows and GTK+ to handle network interaction, URL parsing, and so forth.

Currently this work is pending review at WebKit.org, under 17730 and ~~17985~~. I've also extended the build-webkit interface to support a new --cairo flag that generates a Cairo/cURL build. You can find this (also pending) under 17952.

Note that you will probably need to apply some final WebKit patches to get a clean build. See 17484 for this handful of changes.

Scenes from an Acid Test

2008-03-28T07:44:09+00:00

In our earlier Acid3 post, I mentioned that the final test we passed, test 79, was super tough. This test covered many details of SVG text layout and font support. To pass it, we had to fix many bugs. Unless you are a hardocore standards geek you may not find all these details exciting, but since we talked a bit about our other recent fixes, I thought I’d tell the story. This subtest was originally contributed by Cameron McCormack.

Bug 1: DOM Support for the altGlyph element

I started on test 79 as a weekend hacking lark. While I have hacked a little on the SVG code, it wasn’t my top area of expertise, and I hadn’t looked at the text layout code at all, so I figured it would be an interesting learning experience. Little did I know that we’d end up racing to fix it.

The first failure we saw on test 79 was that getNumberOfCharacters on an SVG <text> element gave an answer that was off by one. The test hinted that this could be due to improper handling of UTF-16 (something covered in the SVG 1.1 Errata). However, on further study, I realized that our UTF-16 handling was right, but the <text> element contained an <altGlyph> element which we did not recognize, and therefore, according to SVG rules, did not render. For those who are new to text layout, a “glyph” refers to a particular symbol that will be drawn on the screen - most often every character has its own glyph, but it can get more complicated than that.

So, as a first step, in r31240 I made <altGlyph> fully recognized by the engine and allowed it to render initially as a <tspan> element. That’s sort of SVG’s equivalent of an HTML <span>, it just renders its text contents.

After landing the fix, I saw that the code testing character positions got a bad position for character 2.

Interlude: Modified Test Case

At this point, I realized that we’d probably get a lot of bad positions, and it would help to see all the problems at one go, instead of one at a time. Acid3 only reports the first failure on any given test. So I saved off a local copy, hacked it to report every failure on test 79, and changed it to test the spaces between characters instead of the character positions. Any error in measuring one character would propagate to all subsequent characters, so it was more useful to look at the differences in positions (”advances” in typography lingo). This immediately made it obvious that by far the most common failure was failure to support multi-character glyphs in SVG Fonts correctly.

Bug 2: Multi-character Glyphs

SVG has a feature to allow specification of glyphs that match more than one character. You can use this to do things like create ligatures. For example, it is common for proportional fonts to include a special glyph for the combination “fi”, since those letters can look nicer if drawn together in a special way.

We had the basics of code to support this. However, the problem was that our code only measured one character at a time. There was no way for the font code to decide to pick a glyph for more than one character because it only saw one at a time, and there was no way for it to report back how many characters a glyph matched. So even though the drawing code sort of got this right, the metrics were based on one-character glyphs. In r31310 I fixed this.

Interlude: Studying the Test Case

After this fix, I studied the test case to classify the remaining failures. I realized there was probably more than one bug, and if I documented them other people could help, or just continue the bug for me if I did not have time.

I found four separate remaining bugs: incorrect priority of SVG glyph matching (it picked the longest match instead of the first), failure to consider the xml:lang attribute in glyph matching, failure to support explicit kerning pairs, and failure to render the actual alternate glyph selected by altGlyph.

Bugs 3 & 4: Glyph Selection

After studying the SVG spec for text, I realized that the data structure we were using for glyph selection was not right. SVG fonts require you to pick the first glyph that matches, in the order in which they are specified, with a number of different rules in addition to text (you have to consider language and the multiple forms of Arabic characters for instance). We just had a hashtable of glyphs, and looked for a candidate by checking possible character runs from longest to shortest. That matched in the wrong priority, and did not properly handle lang at all.

I decided to change the GlyphMap to an n-ary trie (or “prefix tree”), with a vector of possible glyphs at each node, and a hashtable for child nodes. I also stored a “priority” value based on the position of the glyph in the tree. To do lookup, I would walk the trie one character at a time based on available characters, collecting all the glyphs found at each level. Next, the glyphs are sorted by priority. Finally, this vector of candidate glyphs is scanned to find the first that matches the additional constraints such as Arabic form.

Opera Brings its “A” Game

Making a fancy new data structure was a fair bit more complicated than my last two fixes, so I was hacking on this for a couple of days. On Wednesday morning, I heard that Opera was going to announce an Acid3 score of 98/100. The WebKit developers who had been noodling on Acid3 realized that we had fixes in progress for most of the remaining issues, and could likely pass the test by the end of the day, and get it out there.

At this point, I would like to commend the Opera developers for their achievement. At the time they posted the 100/100 screenshot, we had no idea there was a bug in test 79, and hoped at best to be the first to release a 100/100 public build, and both our teams could get some credit and positive exposure. It was not until we were fixing the very last bug in our code that we spotted the bug in the test, as you’ll see below.

Anyway, once we realized it was game on and Opera was much further ahead than we expected, we decided to complete our fixes. Eric fixed handling of charset encoding errors in XML, Antti got two SMIL test fixes in, and I cleaned this patch up, made a regression test, and landed it in r31324 and r31325. (We have a policy that every fix has to come with an automated regression test, no matter how much we’d like to rush - this is so we can move faster in the long run, by having a comprehensive regression test suite that will catch mistakes. Even with all that I had a bit of a commit oops but the team caught it right away, thus the two revisions.)

Bug 5: altGlyph Rendering

At this point, I had a problem. Niko, who had originally written the SVG font and text code, was busy with school, and I’d just learned all about the SVG text system by fixing these bugs, so I was the top expert and sort of on the hook. But there were two bugs left on these test, and neither was trivial to fix. I decided to split the remaining work with rendering master Dave Hyatt. I asked him to take on the altGlyph fix while I took care of kerning.

It turned out there were actually two different problems here. The altGlyph lookup was by ID, but somehow the glyph element wasn’t getting into the id map. With help from Darin and others on the team, Hyatt managed to figure out that we were handling the “id” attribute improperly for the SVG <glyph> element.

The second problem was actually choosing the alternate glyph and using it for metrics and rendering. This turned out to be simpler than it might seem, as it could be handled almost entirely in the SVG font machinery.

You can see the gory details of Hyatt’s fix in r31338. I helped him out with the test case for this, and for a while he thought his code was broken because I sent him a test that showed red boxes when it passes. Kids, never do this in your browser tests. Green for pass, red for fail.

Bug 6: Kerning

The final bug was support for kerning. It was pretty easy to add support to the SVG DOM for the <hkern> element, and to build up a vector of kerning pairs. What was tricky was storing enough info to decide when a kerning pair applied, and the match algorithm to help determine applicability. Kerning pairs can be specified in two ways in the SVG spec, by Unicode value or glyph name.

Darin was looking over my shoulder as I was reading the spec, because I hoped for his help on part of this, the matching algorithm. It was at this point we realized the test had a bug. It had an <hkern> element with a u1 attribute of “EE”, and expected that kerning to apply. But that’s neither a comma-separated sequence of characters nor a Unicode range, which is the syntax the SVG 1.1 spec for <hkern> elements requires. This meant that you couldn’t possibly pass this test without violating the SVG spec. I let Acid3 editor Ian Hickson know right away, and confirmed the error with Cameron, the original author of test 79. While they mulled over how to fix the test (Ian has been very responsive to fixing the few errors that crept into this very complex test), Darin and I continued to work on the final bug.

At last, we managed to pass around the glyph info and apply the matching correctly. We decided to handle the full complexity of the SVG spec for this, even though we could have cut corners just to pass the test, since it didn’t test every possible form of kerning pair. In the meantime, Ian had fixed the bug in the test and blogged about it. At last I saw the 100/100 on my screen for the first time. Everyone egged me on to commit but I insisted on getting the patch reviewed and creating a regression test, cause on WebKit that is how we roll. Finally with r31342 we had a score of 100/100, available to the public. And the rest is history.

By Way of Contrast

As you can see, this test was pretty rigorous, and we did a lot of hard work to make it pass. We fixed a lot of bugs, ranging from basic to obscure and easy to advanced. We didn’t have code just lying around that got us most of the way there.

Not all of the tests on Acid3 were equally stringent. Tests 75 and 76 are SVG Animation tests, contributed by Erik Dahlström. We had the beginnings of an implementation of this feature, but it was fairly incomplete and we had it disabled with ifdefs, and had chosen not to ship it in past releases. We believe in incremental development of new features, so we were prepared to turn it on and fix the bugs needed to pass the tests. We thought this would take a lot of extra work. To our surprise, it turned out that the first few of the changes we made on top of the old code were enough to pass the two SVG animation tests.

Antti checked these fixes in, but we don’t think our pre-existing incomplete implementation is truly satisfactory, and it probably wouldn’t be a good idea to ship it as-is in a major public release. We’re not yet satisfied with this code, but it’s a good step forward for our open development trunk.

Thanks

In the end, the main thing that surprised me about Acid3 was how fun it was. Back when Acid2 was all the rage, Hyatt did pretty much all the fixes himself, so the rest of us didn’t have a chance to get into the spirit as much. But Acid3, and the slightly silly competitive atmosphere around it makes Web standards fun.

Web standards can often seem boring compared to super fast performace, whizzy new features, and even the basic Web compatibility work of making sites work properly. Interoperability is critical to the Web as an open platform, but it can be difficult to explain to regular users why it’s so important. The Acid tests make web standards fun, for browser developers, for Web designers, and for regular users. Whatever the intrinsic value of the tests may be, I think we should all thank Ian Hickson and all the test contributors.

I’d also like to thank Opera for giving us some serious competition and making this a real horse race. We have huge respect for their developers and all the work they do on Web standards.

WebKit gets 100% on Acid3

2008-03-27T21:06:56+00:00

Today we reached a milestone with WebKit/GTK+ as it became the first browser engine on Linux/X11 to get a full score on Acid3, shortly after the Acid3 pass by WebKit for Safari/Mac.

Epiphany using WebKit r31371

There is actually still a little work to be done before we can claim a flawless Acid3 pass. Two of the most visible remaining issues in the GTK+ port are :visited (causing the “LINKTEST FAILED” notice in the screenshot) and the lack of CSS text shadow support in the Cairo/text backend which is needed to match the reference rendering.

It’s amazing to see how far we’ve come in the last few months, and great to see the WebKit GTK+ team now playing an active role in the direction of WebCore as WebKit continues to build momentum amongst developers.

Update: We now also match the reference rendering.

WebKit achieves Acid3 100/100 in public build

2008-03-27T02:55:47+00:00

UPDATE We now believe we have a full rendering pass (but not necessarily an animation smoothness pass yet). See the bottom of the post for details.

UPDATE The Windows nightly is now available for download. See below for details.

With r31342 WebKit has become the first publicly available rendering engine to achieve 100/100 on Acid3. The final test, test 79, was a brutal torture test of SVG text rendering. Details of the bugs we fixed will follow. Indeed, we found a critical bug in the test itself that would have forced a violation of the SVG 1.1 standard to pass, so until a few hours ago it was not possible to get a valid 100/100. Acid3 test editor Ian Hickson has the details.

Note: this does not indicate a full pass of Acid3. We have a slight glitch in the text rendering that is likely to be fixed soon (patch in progress). Also, the animation is required to be smooth. On typical machines, if you look really closely, you can see a small glitch in the animation on test 26 because 26 is designed to be a performance test. However, we think we are faster than all other browsers on test 26. What constitutes a smooth animation is somewhat subjective.

This is not just a screenshot, you can pull live from SVN and build to see it yourself, and a fresh nightly build is coming soon.

Update:

Thanks to our own Dan Bernstein, as of r31356 we believe we have a pixel-perfect match for the reference rendering.

Get the fresh hot bits of the latest Mac and Windows nightly builds which include the full reference rendering pass.

Extra special bonus update: Alp Toker reports that the Gtk port now gets 100/100, although it does not yet match the reference rendering.

Enabling SVG Animation: Acid3 99/100

2008-03-27T01:07:56+00:00

In r31334 we enabled the SVG Animation support that has already been in the engine for a while but has not been enabled by default so far. We also implemented support for the beginElement() and endElement() methods. As a result we now pass the Acid3 test 76.

SVG Animation is a specification that has not been widely implemented so far. Reaching the point where various implementations are truly interoperable will take some more effort.

Get the nightly build and try it out yourself! One test to go.

WebKit hits 98/100 on Acid3

2008-03-26T18:16:10+00:00

We fixed our XML processing in r31316 to stop auto-recovering from invalid byte sequences and instead treat invalid bytes as fatal errors, as required by XML 1.0. To quote the spec:

It is a fatal error if an XML entity is determined (via default, encoding declaration, or higher-level protocol) to be in a certain encoding but contains byte sequences that are not legal in that encoding

Internet Explorer also has this strictness requirement (for XML loaded via XMLHttpRequest), thus we believe this added strictness should not cause any real-world compatibility problems. (IE’s behavior can be confirmed by Hixie’s test.)

Once again, enjoy the pretty picture:

or you can grab the latest nightly and try Acid3 yourself!

ElementTimeControl: 97/100

2008-03-26T18:15:04+00:00

We added the ElementTimeControl interface that is part of the SVG Animation specification. This completes Acid3 test 75 and got us up to 97/100. Three to go!

Acid3: NodeIterator fix leaves us with 4 points to go

2008-03-26T01:49:09+00:00

WebKit was still failing on test 2 of Acid3. That’s a NodeIterator test. The problem was a simple one: While NodeIterator objects were rigged to update themselves when nodes are removed from the document, there were a couple of edge cases that weren’t handled quite right. I tried to fix this about a month ago, but got confused. This time I was able to keep my head straight and it took me less than an hour to fix the bug.

We’re passing 96/100 tests now. There are only 4 points to go to get to 100 points. There are also a few loose ends that don’t cost a point and also some reports of a few failures that some see on their computers, but don’t affect most computers.

We’re closing in on 100%!

GDI Text on Windows

2008-03-25T18:47:23+00:00

The version of WebKit that ships with Safari 3.1 on Windows uses CoreGraphics antialiasing for text. The latest WebKit in nightly builds has made good progress on a GDI text rendering mode (i.e., the text rendering matches your OS look/settings). We encourage Windows testers to try out GDI text rendering and file bugs that you find at http://bugs.webkit.org/.

To enable GDI text rendering, you will need to hand edit your preferences file, as there is no visible UI option in Safari 3.1 for this. You will need to set WebKit’s “WebKitFontSmoothingType” preference to a value of “4″.

The preferences file on Windows XP is:

C:\Documents and Settings\<username>\Application Data\Apple Computer\Safari\WebKitPreferences.plist

On Vista, it is:

C:\Users\<username>\AppData\Roaming\Apple Computer\Safari\WebKitPreferences.plist

The values that are listed in Safari’s UI for this preference map to the numbers 0-3.

Note that while you can turn on GDI text rendering in the WebKit that ships with Safari 3.1, most advanced text features will not work. These include stroking and filling text, most advanced text features in SVG, shadows, partially transparent text (rgba/hsla) and text inside a transparency layer (opacity). All of these features should work now in the latest nightlies.

If you have changed the setting in Safari you may have to edit that preference file. It can be found at:

%APPDATA%\Apple Computer\Safari\Preferences\com.apple.Safari.plist

Optimizing Page Loading in the Web Browser

2008-03-24T01:27:54+00:00

It is well understood that page loading speed in a web browser is limited by the available connection bandwidth. However, it turns out bandwidth is not the only limiting factor and in many cases it is not even the most important one.

The graph above shows the time it took to fully load the Wall Street Journal front page (chosen for its complexity which well represents many modern web sites) with a recent WebKit. Browser caches were cleared before each page load. The Mac OS X dummynet facility was used to simulate various network conditions by introducing packet latency and capping the available bandwidth. Since the testing was done against a live web site the actual connection latency was a factor as well (ping time to wsj.com was ~75ms).

From the figure it is clear that while available bandwidth is a significant factor, so is the connection latency. Introducing just 50ms of additional latency doubled the page loading time in the high bandwidth case (from ~3200ms to ~6300ms).

Latency is a significant real world problem. Wireless networking technologies often have inherently high latencies. Packet loss and retransmits due to interference makes the situation worse. Geographical distance introduces latency. Just the roundtrip delay between US East and West Coast is somewhere around 70ms. Loaded web servers may not respond immediately.

Why does latency have such a huge impact on page loading speed? After all, to load a page completely a web browser just needs to fetch the page source and all the associated resources. The browser makes multiple connections to servers and tries to load as many resources in parallel as possible. Why would it matter much if it takes slightly longer to start loading an individual resource? Other resources should be loading during that time and the available bandwidth should still get fully utilized.

It turns out that figuring out “all the associated resources” is the hard part of the problem. The browser does not know what resources it should load until it has completely parsed the document. When the browser first receives the HTML text of the document it feeds it to the parser. The parser builds a DOM tree out of the document. When the browser sees an element like <img> that references an external resource, it requests that resources from the network.

Problems start when a document contains references to external scripts. Any script can call document.write(). Parsing can’t proceed before the script is fully loaded and executed and any document.write() output has been inserted into the document text. Since parsing is not proceeding while the script is being loaded no further requests for other resources are made either. This quickly leads to a situation where the script is the only resource loading and connection parallelism does not get exploited at all. A series of script tags essentially loads serially, hugely amplifying the effect of latency.

The situation is made worse by scripts that load additional resources. Since those resources are not known before the script is executed it is critical to load scripts as quickly as possible. The worst case is a script that load more scripts (by using document.write() to write <script> tags), a common pattern in Javascript frameworks and ad scripts.

The latest WebKit nightlies contain some new optimizations to reduce the impact of network latency. When script loading halts the main parser, we start up a side parser that goes through the rest of the HTML source to find more resources to load. We also prioritize resources so that scripts and stylesheets load before images. The overall effect is that we are now able to load more resources in parallel with scripts, including other scripts.

You can see from the graphs above that these optimizations significantly reduce the impact of network latency and generally improve page loading speed. For example with 50ms of simulated latency and no bandwidth limit, the overall page loading time was 2.8s faster (6.3s to 3.5s). With bandwidth capped to 512kbit/s the improvement was 5.9s (23.8s to 17.9s).

WebKit gets an A+ on Acid3

2008-03-22T11:05:44+00:00

As of revision 31231, WebKit passes Acid3 subtests 23 (bug) and 25 (bug). That brings our score up to 95/100 — an A+! We fixed our parsing of qualified names to match the DOM Level 3 Core specification and now correctly throw NAMESPACE_ERR and INVALID_CHARACTER_ERR exceptions for invalid calls like:
document.createElementNS(null, "foo::bar") or
document.implementation.createDocumentType(":bar", null, null).

Behold the glory:

Update: The latest WebKit nightly build now includes the fixes for these two Acid 3 bugs.

Full Page Zoom

2008-03-21T20:23:32+00:00

WebKit now supports full page zooming on Mac and Windows. Because this feature involves new WebKit API, it’s not something you’ll see in nightly builds by default (since the Safari used with the nightlies calls the text zoom API). I have added a debug preference, though, that will cause the text zoom methods in WebKit to do full page zoom instead.

To try out full page zoom in a nightly, you can type the following in a terminal window:

defaults write com.apple.Safari WebKitDebugFullPageZoomPreferenceKey 1

We encourage people to try out full page zooming and file bugs on the feature.

background-clip: text

2008-03-21T00:54:39+00:00

CSS3 has introduced a property called background-clip that can be used to clip backgrounds to either the border, padding or content box. I have extended this property with a fourth value, text, that causes the background image to clip to foreground text (including decorations and shadows). The shape of the foreground content (including alpha transparency in the content) is applied as a mask to clip background drawing for the box.

Here is an example:
<div style="background: url(http://webkit.org/images/green-background.png), black; border:5px solid black; padding:5px; -webkit-background-clip: text, border; color: transparent"> This background clips to the text. </div>
And here is how it looks (if you try it out in ToT):

This background clips to the text.

This effect can be used with -webkit-text-stroke and a transparent -webkit-text-fill-color to create text with stroked outlines that is “filled” with the background.

In addition, this visual effect can work with fixed backgrounds, so that text can look like it’s “punching a hole” through to the viewport.

Google Summer Of Code

2008-03-18T21:14:27+00:00

Are you a university student? Would you like to get paid to hack on WebKit? WebKit is participating in Google’s Summer of Code. Google will pay you to work on WebKit for the summer. Coding sure beats flipping burgers.

Google begins accepting applications March 24th, 2008. We’ve posted some example project ideas to start your thought processes. Some highlights:

Finish SVG 1.1 - filters, animation, various other bugs
Finish CSS 2.1 or parts of CSS 3 (e.g. paged media)
Web technology support - MathML, Ruby, HTML5, XBL2, ARIA
Port WebKit to your favorite platform
Improve our developer tools (Drosera, Web Inspector) or add your own (e.g. a JS profiler)
Propose your own idea! What cool things should tomorrow’s web browsers do?

Prospective applicants should read Google’s student application instructions and join #webkit on freenode.net to meet the WebKit community. We’re happy to answer any questions about possible projects or mentors. Join #gsoc to ask the Google folks any administrative questions you may have.
We look forward to hacking with you this summer!

WebKit Hits 93/100 in Acid3

2008-03-18T00:15:23+00:00

This one didn’t actually involve any code changes. Rather, the Acid3 test itself was changed as a result of feedback from the browser developers. The issue was some rather obscure details of click() DOM method which are not specified anywhere but are implemented in certain way by all browsers (more details in this thread). The behavior expected by earlier versions of the Acid3 was different and would have broken some web content. The ongoing HTML5 work will allow standardizing these kinds of details.

It is good to see that besides testing many exciting new standards Acid3 also takes real-world web compatibility seriously.