While these features aren’t widely available yet, implementation is progressing and it’s already possible to try out some of the features yourself. Internet Explorer 10 has an implementation of the exclusions processing model, so you can try out exclusions in IE 10 today.

At Adobe we have been focusing on implementing the shapes portion of the specification. We began with an implementation of shape-inside and now have a working implementation of the shape-outside property on floats. We have been building our implementation in WebKit, so the easiest way to try it out yourself is to download a copy of Chrome Canary. Once you have Canary, enable Experimental WebKit Features and go wild!

What is shape-outside?

“Now hold up there,” you may be thinking, “I don’t even know what a shape-outside is and you want me to read this crazy incomprehensible specification thing to know what it is!?!”

Well you’ll be happy to know that it really isn’t that complex, especially in the case of floats. When an element is floated, inline content avoids the floated element. Content flows around the margin box of the element as defined by the CSS box model. The shape-outside CSS property allows you to tell the browser to use a specified shape instead of the margin box when wrapping content around the floating element.

The current implementation allows for rectangles, rounded rectangles, circles, ellipses, and polygons. While this gives a lot of flexibility, eventually you will be able to use a SVG path or the alpha channel of an image to make it easier to create complex shapes.

How do I use it?

First, you need to get a copy of Chrome Canary and then enable Experimental WebKit features. Once you have that, load up this post in Chrome Canary so that you can click on the images below to see a live example of the code. Even better, the examples are on Codepen, so you can and should play with them yourself and see what interesting things you can come up with.

Note that in this post and the examples I use the unprefixed shape-outside property.
If you want to test these examples outside of my Codepen then you will need to use the prefixed -webkit-shape-outside property or use (which is a built in option in Codepen).

We’ll start with a HTML document with some content and a float. Currently shape-outside only works on floating elements, so those are the ones to concentrate on. For example: (click on the image to see the code)

You can now add the shape-outside property to the style for your floats.

.float {
  shape-outside: circle(50%, 50%, 50%);
}

A circle is much more interesting than a standard rectangle, don’t you think? This circle is centered in the middle of the float and has a radius that is half the width of the float. The effect on the layout is something like this:

While percentages were used for this circle, you can use any CSS unit you like to specify the shape. All of the relative units are relative to the dimensions of element where the shape-outside is specified.

Supported shapes

Circles are cool and all, but I promised you other shapes, and I will deliver. There are four types of shapes that are supported by the current shape-outside implementation: rectangle, circle, ellipse, and polygon.

rectangle

You have the ability to specify a shape-outside that is a fairly standard rectangle:

shape-outside: rectangle(x, y, width, height);

The x and y parameters specify the coordinates of the top-left corner of the rectangle. This coordinate is in relation to the top-left corner of the floating element’s content box. Because of the way this interacts with the rules of float positioning, setting these to anything other than 0 causes an effect that is similar to relatively positioning the float’s content. (Explaining this is beyond the scope of this post.)

The width and height parameters should be self-explanatory: they are the width and height of the resulting rectangle.

Where things get interesting is with the six-argument form of rectangle:

shape-outside: rectangle(x, y, width, height, rx, ry);

The first four arguments are the same as explained above, but the last two specify corner radii in the horizontal (rx) and vertical (ry) directions. This not only allows the creation of rounded rectangles, you can create circles and ellipses as well. (Just like with [border-radius][border-radius].)

Here’s an example of a rectangle, a rounded rectangle, a circle, and an ellipse using just rectangle syntax:

If you’re reading this in Chrome Canary with exclusions turned on, play around with this demo and see what other things you can do with the rectangles.

circle

I already showed you a simple circle demo and you’ll be happy to know that’s pretty much all there is to know about circles:

shape-outside: circle(cx, cy, radius);

The cx and cy parameters specify the coordinates of the center of the circle. In most situations you’ll want to put them at the center of your box. Just like with rectangles moving this around can be useful, but it behaves similarly to relatively positioning the float’s content with respect to the shape.

The radius parameter is the radius of the resulting circle.

In case you’d like to see it again, here’s what a circle looks like:

While it is possible to create circles with rounded rectangles as described above, having a dedicated circle shape is much more convenient.

ellipse

Sometimes, you need to squish your circles and that’s where the ellipse comes in handy.

shape-outside: ellipse(cx, cy, rx, ry);

Just like a circle, an ellipse has cx and cy to specify the coordinates of its center and you will likely want to have them at the center of your float. And just like all the previous shapes, changing these around will cause the float’s content to position relative to your shape.

The rx and ry parameters will look familiar from the rounded rectangle case and they are exactly what you would expect: the horizontal and vertical radii of the ellipse.

Ellipses can be used to create circles (rx = ry) and rounded rectangles can be used to create ellipses, but it’s best to use the shape that directly suits your purpose. It’s much easier to read and maintain that way.

Here’s an example of using an ellipse shape:

polygon

Now here’s where things get really interesting. The polygon `shape-outside` allows you to specify an arbitrary polygonal shape for your float:

shape-outside: polygon(x1 y1, x2 y2, ... , xn yn);

The parameters of the polygon are the x and y coordinates of each vertex of the shape. You can have as many vertices as you would like.

Here’s an example of a simple polygon:

Feel free to play with this and see what happens if you create more interesting shapes!

Putting content in the float

The previous examples all had divs without any content just to make it easier to read and understand the code, but a big motivation for shape-outside is to wrap around other content. Interesting layouts often involve wrapping text around images as this final example shows:

As usual, you should take a look and play with the code for this example of text wrapping around floated images. This is just the beginning of the possibilities, as you can put a shape outside on any floating element with any content you want inside.

Next steps

We are still hard at work on fixing bugs in the current implementation and implementing the rest of the features in the CSS Exclusions and Shapes specification. We welcome your feedback on what is already implemented and also on the spec itself. If you are interested in becoming part of the process, you can raise issues with the current WebKit implementation by filing bugs in the WebKit bugzilla. If you have issues with the spec, those are best raised on the www-style mailing list. And of course, you can leave your feedback as comments on this post.

I hope that you enjoy experimenting with shape-outside and the other features we are currently working on.

The CSS 2.1 specification defines a box model to represent the layout of a document and pretty much everything is a box. Normal flow nodes (e.g. not absolutely positioned) are laid out child by child starting at the top of their parent element box. If an element’s box is too small to fit all the content, the content is said to overflow and this overflow can either be visible or get clipped.

Fragmentation is different from overflow because it allows flowing the content through multiple boxes called fragmentation containers – fragmentainers for short. When the end of the current fragmentainer is reached a break occurs and the layout continues within the next fragmentainer. Using CSS, authors can also force breaks to occur after or before an element and even avoid them altogether.

The important detail to remember is that fragmentation doesn’t mean taking the overflow of a box and visually moving it to another one. Fragmentation happens during the layout and affects the dimensions of the content boxes.

There are a few specifications in CSS based on fragmentation:

• CSS3 Pagination - the document is laid out so it can fit on pages; the pages act as fragmentainers.
• CSS3 Multi-column - the element defines a number of columns that fill its box and where the content is laid out; the columns act as fragmentainers.
• CSS3 Regions - selected content forms a flow that’s laid out inside boxes called regions; the regions act as fragmentainers.

All of these specifications share common concepts covered by the CSS3 Fragmentation specification.

Example of a paragraph flown in two regions.

Fragmentation in WebKit

The Layout Process

To fully understand the concepts presented here you should know a bit about how layout works in WebKit. There are some nice articles on the Web covering the basics such as Bem’s article.

Long story short, the DOM tree is internally mapped to a render tree that is used to build up the box properties for every node. The render tree is made up from objects like RenderBox, RenderBlock, RenderInline etc. that represent the concepts defined in CSS2.1. During layout this tree is traversed and the various geometrical properties of the renderers are computed based on the style values. In the end all the elements have their box information computed.

As a side note, you’ll notice the symbols inside WebKit are usually named using the “pagination” or “page” terminology. This is for historical reasons, but most of the time the pagination concepts map to the fragmentation ones – pages, columns or regions.

There were a couple of ways the fragmentation behavior could have been implemented in WebKit. One of them was to have a renderer for each element fragment. For instance a simple paragraph with ten lines where there’s a break after the fourth one, we would have had one renderer with four lines in the first fragmentainer and a second renderer with six lines in the second fragmentainer. Both of the renderers would belong to the initial element. This approach is difficult to implement correctly and maintain because of the complexity it brings to the codebase. Additionally, it is also very risky from a security standpoint as it can introduce many subtle memory management bugs.

A rule of maximum one renderer per DOM node was created because of these concerns. Fragmentation is implemented by shifting the monolithic boxes (boxes that can’t be fragmented, such as line boxes – rectangles wrapping each line of text) so that they don’t overlap with the breaks. The correct rendering is obtained during the painting phase by placing each fragment exactly where it is supposed to appear in the fragmentainer. More about this topic in the next section.

In the case of unforced breaks, a position adjustment, called pagination strut in the codebase, is attached to the boxes during layout. This value represents a shift offset from the default layout position to the next fragmentainer in case the box doesn’t fit the current one. This offset needs to be stored separately on each box, not as a part of the top position because it’s not an attribute of the renderer. It’s a layout artifice that helps measuring the fragmented boxes. For example, if a block is collapsing at the top margin with its container (e.g. it’s the first child) and it also has a pagination strut, that offset will be transferred to the container. This makes sense because both the block and the container need to be placed in the next fragmentainer even though it’s the child that won’t fit.

The same rule applies to the first line box of a block. Also, during subsequent layouts it’s possible for an element to shift in the block-flow direction. The line boxes pagination struts need to be recomputed because the shift offsets are most likely different after the element changed position.

When a line doesn’t fit the current fragmentainer it is shifted using the pagination strut.

As an example, in the case of the example above, the first four line boxes would be positioned normally in the first fragmentainer. The fifth line box may need to have a pagination strut defined if it fits only partially in the first fragmentainer. This pagination strut would logically shift the line inside the next fragmentainer. The rest of the lines are all placed normally in the second fragmentainer.

In the case of forced breaks, the pagination strut is no longer used because the authors directly specify where the breaks occur. The boxes are positioned inside their container so they respect the break condition.

Each type of fragmentation layout has its own specialized behavior. The multi-column elements have the ColumnInfo object attached to them. It contains information about the number and the width of the columns, the distance between breaks (used to balance the columns if they have auto-height) etc. This object is also pushed on the layout state stack so it can be accessed from any point inside the render tree.

The regions implementation is currently the most complex type of layout that makes use of fragmentation. The content node renderers are not attached to their DOM parent renderer. Instead, they are moved to a special object, RenderFlowThread, that sets up a pagination context when it is laid out. These renderers need to hold and use various information about the flow thread: the regions size, how the descendant boxes change width in every region they are flowing into etc. Because the concept of the flow thread is so generic there are plans to port the multi-column implementation on top of it.

The Layout Performance

From a performance perspective, the layout process will always be slower for fragmented content because the engine can’t apply the same optimizations that are made for continuous vertical content. For example, without the possibility of fragmentation, updating the top margin of an element can shift it on the vertical axis but no relayout may be needed. If the element is enclosed in a fragmentation context, by shifting the element it’s possible it won’t fit any more inside the fragmentainer, triggering a break. To cover this case, a relayout of the element is always required.

The layout engine is usually optimized for both speed and memory consumption. This means fragmentation code is used only when necessary: if there is a printing context, if the node being laid out is a part of a multi-column element or if the renderer belongs to a flow thread. The logic for enabling the fragmentation code can be found inside the LayoutState class. During layout, a stack of LayoutState objects is created and stored on the root of the render tree, the RenderView. Any renderer can query the top of this stack to determine if the content can be fragmented or not.

The Painting Phase

The painting of the renderers in WebKit is handled by the RenderLayer tree. For some renderers the engine creates layers that are used to paint the document in the correct order (e.g. with respect the z-index restrictions). Layers are always created for the renderers that fragment, such as multi-column blocks or RenderFlowThread objects. Because of this, multi-column elements and regions create stacking contexts and are painted as a single item.

For regions, when the painting operation occurs, the engine takes into account the fragmentation properties of the renderer and shifts the layer to the correct position so the painting is always executed inside the correct fragmentainer. The content not belonging to the current fragmentainer is clipped so the engine always paints only the content that should be displayed in a certain area. The mechanism is in some ways similar to how sprites (e.g. CSS Sprites) work.

The RenderFlowThread is painted in the two regions at the offsets corresponding to each content fragment.

For example, let’s say the paragraph above is flown into regions A and B. When region A is painted, the flow thread layer is called to paint in the fragmentainer box. It will paint the first four lines and then blank space until the bottom of the fragmentainer because the fifth line was shifted at layout-time using the pagination strut. When region B is painted, the flow thread layer is called again to paint inside the fragmentainer box, but at a new offset, where the region B fragment starts (top of the fifth line). The last six lines of the paragraph are painted.

Something similar happens with the multi-column blocks. However, the main difference is the fragmentainers for multi-column blocks don’t have their own layers. By using the same layer as the multi-column block the content is able to use advanced graphics features such as 3D transforms and video tags (see WebKit Compositing for more details about how accelerated layers work).

In the case of a flow thread, making its layer work with the region layers is one of the major challenges that need to be solved. As a consequence of this problem, content layers that require accelerated compositing (e.g. video layers) will not work correctly inside flow threads.

Conclusions

The modern fragmentation concepts are not yet fully implemented inside WebKit. There are some issues with the handling of forced breaks and the avoid value is implemented only for the break-inside property. The widows and orphans properties were just recently fully enabled.

On the CSS Regions side there’s some work left to do to achieve a smooth integration with the layers and compositing subsystem. Testing is also much needed to ensure good integration with other Web features.

Over the past two years, my team in Adobe has been actively working on the CSS Custom Filters specification (formerly CSS Shaders), which is just one part of the greater CSS Filters specification. Alongside the spec work, we have been working on the CSS Custom Filters WebKit implementation, so I’ve decided to write this blog post to explain how this is all being implemented in WebKit, giving an high-level conceptual overview of the game.

Support for OpenGL shaders on general DOM content has been one of the noted features for the latest Chrome releases. Users and web developers are excited about the ability to apply cinematic effects on their pages.

Shaders, Shaders, Shaders

I’ve often been asked “what is a shader?”; well, shaders are short programs that run on the GPU that – unlike regular programs – solely deal with bitmaps (textures) and 3D meshes, performing specific operations on pixels (called fragments) and vertices. You can get a more in-depth explanation of shaders on Wikipedia.

Roughly speaking, the reason why these small programs run on the your graphic card’s processor (the GPU) instead of the regular CPU is that GPUs are very good at performing ad hoc math operations in parallel. While the GPU is busy performing graphical operations, your CPU is idle and ready to perform other tasks. Everything is faster and snappier.

In our case, the texture passed to the graphic pipeline is styled DOM content, your page content. This means that with one line of CSS and a shader, you can get splendid and astonishing results, just take a look at the image at the beginning of this post.

HTML5Rocks has a great post covering the whole idea behind CSS Custom Filters with an example of their capabilities so I won’t spend too many words on how to use them, instead I’ll be focusing on what is the general idea behind the implementation. Let’s start!

Parsing and Style Resolution

The life of a CSS Shader Custom Filter starts with the CSS Custom Filter declaration. With the currently implemented WebKit syntax, it might look like the following:

#myElement {
    -webkit-filter: custom(url(vertex.vs) none)
}

This CSS is firstly encountered by WebKit’s CSSParser, which – as the name might suggest – is the component within WebKit responsible for CSS parsing. Raw text data gathered from this object is then computed by WebKit’s StyleResolver and from there, a CustomFilterOperation is created. This class will contain all the major information about the Custom Filter you’ve asked to use, such as its parameters. It also references the program, a CustomFilterProgram, which is a vertex shader and fragment shader pair, that will be applied to the texture (your styled DOM content).

Here’s a picture of the happy event:

PassRefPtr StyleResolver::createCustomFilterOperation(WebKitCSSFilterValue* filterValue)
{
    // ...snip...
    RefPtr program = StyleCustomFilterProgram::create(vertexShader.release(), fragmentShader.release(), programType, mixSettings, meshType);
    return CustomFilterOperation::create(program.release(), parameterList, meshRows, meshColumns, meshType);
}

Computing and Rendering

The RenderLayer tree is one of the many trees in WebKit and it’s currently being used, among other things, to deal with group operations such as opacity, stacking contexts, transforms and to do things like scrolling and accelerated compositing: it’s a huge huge piece of code that defines the word “complexity”.:-)

What happens after the parsing and the style resolution is most interesting: when a DOM element has a filter associated with it, it receives its own RenderLayer. When this happens, the relevant DOM content is painted in an image buffer and then sent to the GPU for the “shading treatment” as a regular texture. All this starts to take place thanks to RenderLayerFilterInfo which, among other things, downloads the shaders as external resources and calls the RenderLayer back to notify it that everything’s ready to repaint.

The computing magic begins when a RenderLayer starts to iterate on all the filters associated with it:

FilterOperations RenderLayer::computeFilterOperations(const RenderStyle* style)
{
	// ...snip...
        for (size_t i = 0; i < filters.size(); ++i) {
        RefPtr filterOperation = filters.operations().at(i);
        if (filterOperation->getOperationType() == FilterOperation::CUSTOM) {
	// ...snip...
            CustomFilterGlobalContext* globalContext = renderer()->view()->customFilterGlobalContext();
            RefPtr validatedProgram = globalContext->getValidatedProgram(program->programInfo());
	// ...snip...
}

For every custom filter, a validated version of the program (see next paragraph) is requested; this is then appended to the list of the associated filter operations.

The actual rendering will take place in the FilterEffectRenderer class where the “filter building” operation will start in a surprisingly straightforward manner:

bool FilterEffectRenderer::build(RenderObject* renderer, const FilterOperations& operations)
{
	// ...snip...
        effect = createCustomFilterEffect(this, document, customFilterOperation);
	// ...snip...
}

FilterEffectRenderer::createCustomFilterEffect is the method that will rule them all. Take a look at it, it’s just gorgeous!

A word about security

Among the other things, shaders deal with pixels which means that a texture can be sampled (read). This translates into a potential security risk: we don’t really like the idea of malicious shaders reading your page content. Imagine to what would happen if anyone was able to push a shader capable of making a screenshot of your private messages on some social network.

In light of this we do enforce restrictions on shader code before it’s sent to the GPU. We do this by validating and rewriting the shaders in a controlled and secure fashion, and CustomFilterValidatedProgram serves just this purpose, one of its goals is to avoid texture sampling, meaning that the shaders cannot read pixels from your page content anymore. Most of the validation work actually relies on ANGLE, an open source library used by many other projects, including WebKit and Gecko, for WebGL validation and portability.

If you want to have an idea of the kind of validation we perform, pay attention to CustomFilterValidatedProgram: it might prove a very learning reading.

Wrapping up

Currently, we’re working with the CSS Working Group to make the CSS Custom Filters syntax more elegant and future-proof. As with any new web feature, you can expect changes. Stay tuned for more information on upcoming improvements!

Getting and building the code

This is entirely optional, so if you don’t feel like setting this up or don’t have a machine powerful enough to do the build, feel free to skip to the next section. I will put in links to all of the code that I reference throughout the document, so you should be able to follow along with nothing more than the web browser you are using to read this.

Note that this section does not attempt to be a complete guide to setting up a build environment and getting a working build. That would be an entire blog series of its own!

Getting the code

If you’re still with me, before you build anything, you’ll need to get a copy of the source code. WebKit uses Subversion for source control; however, most developers work with the Git mirror. If you’re on Windows, you should jump directly to the Building the code section below, as you need to have the code checked out to a specific location in order for the code to build. Otherwise, you can continue with this section.

Installing Git on Linux and Mac OS X

Installing Git is pretty straightforward on Linux and Mac OS X. On Linux, I’d suggest that you use your distribution’s package manager, but if you can’t do that for some reason, you can download Git from the Git Homepage.

For recent versions of Mac OS X, it is included in the Xcode developer tools, and you will need them to build the code anyways. Once you’ve installed Xcode, you will need to install the command line tools, which is located under Xcode -> Preferences -> Downloads in Xcode 4.5.2, and in a similar location in earlier versions.

Downloading the source

Once you have Git installed, grabbing the source is pretty straightforward. First, make sure you have at least 4 gigs of free space. Then, open a terminal, find a suitable directory, and run the following command:

git clone git://git.webkit.org/WebKit.git WebKit

This will take awhile, but when it’s done, you’ll have your very own copy of the WebKit source code.

That’s great, but I still don’t get this Git thing

Explaining how to use Git is beyond the scope of this post, but here are a couple of resources:

• Using Git With WebKit: Documentation on using Git with WebKit
• Pro Git: Free, professionally written book on Git

Building the code

WebKit is designed to be able to run on many different platforms. To facilitate this, functions like graphics and networking have abstraction layers that allow an implementation for a specific platform to be plugged in. This combination of the platform independent part of WebKit with the low level bindings for a specific platform is called a port.

Note that while there are ports that are operating system specific, like the Mac and Windows ports, there are also ports for platforms like Qt, which is a library that can be used on many different operating systems. The short of it is that in order to build WebKit, you need to choose the proper port to build for your purposes.

The best place to start to learn how to build WebKit is to take a look at the documentation on installing the developer tools to build webkit. It lists out the most common ports with either instructions in the page or links to the Wiki documentation on how to set up a development environment for that port. I would suggest using the Mac port if you’re on a Mac, and the Windows port if you’re on Windows. If you’re on Linux, you can choose between the Gtk, Qt, and EFL ports. If you don’t care or don’t know which one to choose, you could use the Gtk port if you’re using Gnome, and the Qt port if you’re using KDE.

If you’re building a port other than the Mac or Windows port, all of the build instructions are on the wiki page about that port, which I linked to in the paragraph above. Otherwise, you will want to read the build instructions for the Mac and Windows ports.

There are more ports than the ones I mentioned here; however, when doing WebKit development, it is probably easiest to start with one of the ports I mentioned above. If you would like to know about others, there is a list of ports on the WebKit wiki.

Help! I followed all the instructions and it still doesn’t work!

If you can’t get your chosen port to build, or if you’re unsure of which port to choose, there is a page of contact information for the WebKit project. I would suggest starting by sending a message to the webkit-help mailing list, as that will get you in contact with people that should be able to help with any build problems or questions that you may encounter. You can also contact the developers on IRC: the #webkit channel on irc.freenode.net is WebKit central.

Visualizing layout

The layout process determines what features of a web page get drawn into which locations. However, when starting out, it can be hard to link the C++ code to the visual result that you see in your browser. Probably the easiest way to make this connection in a visual way is to modify the code that draws everything to the screen. This drawing step happens after layout, and WebKit calls it painting.

Basics of painting

After layout has finished, the process of painting begins. It happens in a very similar way to layout: each rendering class has a paint method that is analogous to the layout method we discussed in the last post. This paint method is responsible for drawing the current renderer and it’s children onto the display.

The CSS specification defines the painting order for elements, and the WebKit implementation has painting phases for all of these steps. As with many of these things, it is too complex to explain here in its entirety, but the rules of the painting order ensures that all of CSS’s positioning rules are rendered properly. This must be taken into account when thinking of where in the individual paint methods changes should be made.

The paint method can be instrumented to draw the outline of the area painted by the class. This can make it much easier to understand which parts of the code create which parts of the rendered page.

What does it look like?

To generate the above screenshot, RenderBlock::paint method (Look in Source/WebCore/rendering/RenderBlock.cpp for the definition) was instrumented to draw a green border around the block itself.

Drawing the outlines

The C++ code that generated those lovely green outlines is the following:

Color color;
color.setRGB(0, 255, 0);
paintInfo.context->setStrokeColor(color, style()->colorSpace());
paintInfo.context->strokeRect(overflowBox, 2);

Let’s break this down line by line:

Color color;

This creates a Color object. It is hopefully not surprising that this object represents a color, and will be used to set the color that we are going to draw our border with.

color.setRGB(0, 255, 0);

This call sets the color for our Color object. It takes 3 numbers between 0 and 255, each one representing the amount of red, green, or blue that makes up the color. For simplicity, I just went with entirely green, but you could do any sort of fancy thing you like here. Setting the color to different values could come in handy if you want to instrument multiple classes at once: each could have a different color, making it easy to tell them apart.

paintInfo.context->setStrokeColor(color, style()->colorSpace());

Now’s when things get more complex. paintInfo is an instance of PaintInfo that is passed as an argument to the paint method. PaintInfo is a simple structure that contains the state of the painting operation as well as the object used to actually call the native drawing routines. That object is the context member of PaintInfo. This object is actually a facade to provide a platform independent API for drawing. It is declared in platform/graphics/GraphicsContext.h, and there are corresponding platform specific implementations that it uses depending in which WebKit port is in use.

If you have done graphics programming before (Even using HTML’s canvas element), you will probably find the use of the GraphicsContext familiar. The methods may have different names, but the underlying concepts of the API are exactly the same. For example, this setStrokeColor call sets the color that is used by subsequent drawing operations that use this context.

The last piece of this line that I should explain is the style() call. This gets the CSS style information for the RenderBlock, and queries it for the color space. This is one of the things that will need to change when modifying this code to work in paint methods in other objects, since there are some cases when a renderer delegates painting some part of it’s content to another class that itself is not a renderer. In those cases, that class has a reference to the renderer it is attached to, and the style() method can be called via that member. In most cases, this member is called m_renderer, so this call changes to m_renderer->style()->colorSpace(). I give an example of this case later in this post.

paintInfo.context->strokeRect(overflowBox, 2);

This is the call that actually draws the border rectangle. The overflowBox is the dimensions of the block plus any visible overflow: that’s the entire area of the page that is rendered by this block and its children. The second argument to strokeRect is the width of the line used to draw the rectangleA.

Where is this code added?

Of course, this code cannot just be added at random, you need to put it in a specific place in the paint method. As of this writing, the paint method in RenderBlock.cpp looks like the following:

void RenderBlock::paint(PaintInfo& paintInfo, const LayoutPoint& paintOffset)
{
    LayoutPoint adjustedPaintOffset = paintOffset + location();

    PaintPhase phase = paintInfo.phase;

    // Check if we need to do anything at all.
    // FIXME: Could eliminate the isRoot() check if we fix background painting
    // so that the RenderView paints the root's background.
    if (!isRoot()) {
        LayoutRect overflowBox = overflowRectForPaintRejection();
        flipForWritingMode(overflowBox);
        overflowBox.inflate(maximalOutlineSize(paintInfo.phase));
        overflowBox.moveBy(adjustedPaintOffset);
        if (!overflowBox.intersects(paintInfo.rect))
            return;
    }

    bool pushedClip = pushContentsClip(paintInfo, adjustedPaintOffset);
    paintObject(paintInfo, adjustedPaintOffset);
    if (pushedClip)
        popContentsClip(paintInfo, phase, adjustedPaintOffset);

    // Our scrollbar widgets paint exactly when we tell them to,
    // so that they work properly with z-index.  We paint after we painted
    // the background/border, so that the scrollbars will sit above
    // the background/border.
    if (hasOverflowClip() && style()->visibility() == VISIBLE &&
            (phase == PaintPhaseBlockBackground ||
                phase == PaintPhaseChildBlockBackground) &&
            paintInfo.shouldPaintWithinRoot(this))
        layer()->paintOverflowControls(paintInfo.context,
            roundedIntPoint(adjustedPaintOffset), paintInfo.rect);
}

I’m not going to go over this one line at a time, as by the time you read this, this method may or may not look the same. However, I would like to share where I placed the code and the rationale behind it so that hopefully you will still be able to instrument the code yourself even if it has changed, and will be able to think about how to instrument the paint methods in other render classes as well.

When looking for a place to put the code in this method, the first thing I needed to find was where I could find a LayoutRect that represents the area that this renderer will paint into. This is the dimensions of the block plus any visible overflow. This value is usually used early on in the paint method to determine if the current block is actually in area to be painted (paintInfo.rect). In RenderBlock::paint, you can see this in the if statement following the helpful comment “Check if we need to do anything at all.”:

if (!isRoot()) {
    LayoutRect overflowBox = overflowRectForPaintRejection();
    flipForWritingMode(overflowBox);
    overflowBox.inflate(maximalOutlineSize(paintInfo.phase));
    overflowBox.moveBy(adjustedPaintOffset);
    if (!overflowBox.intersects(paintInfo.rect))
        return;
}

So overflowBox is our variable, which you might remember from the instrumentation code example above. Now, we need to determine where to put our instrumentation code. In this case, unless we want to move the definition of overflowBox, we don’t have much choice: it must go in the body of the if statement above. Since we don’t want to draw the outline if the block is not in the area to be painted, we should put it after the return statement at the end, like so:

if (!isRoot()) {
    LayoutRect overflowBox = overflowRectForPaintRejection();
    flipForWritingMode(overflowBox);
    overflowBox.inflate(maximalOutlineSize(paintInfo.phase));
    overflowBox.moveBy(adjustedPaintOffset);
    if (!overflowBox.intersects(paintInfo.rect))
        return;

    Color color;
    color.setRGB(0, 255, 0);
    paintInfo.context->setStrokeColor(color, style()->colorSpace());
    paintInfo.context->strokeRect(overflowBox, 2);
}

And now if we build and run the code, we should see an effect like in the screenshot above. It is also very interesting to launch the web inspector with this active.

More complex paint methods

The paint method of RenderBlock makes for a nice example because it is pretty small and it is pretty straightforward to see how to instrument it. (Most of the complexity is nicely factored out into helper methods.) However, this is not the case for the paint method in InlineFlowBox. InlineFlowBox is used to manage flows of inline content, like text.

I am not going to reproduce the entirety of InlineFlowBox::paint here, but you should be able to follow along by either opening the file in your favorite editor if you opted to download the code, or by looking at InlineFlowBox.cpp on Trac.

While this is a more complex paint method, the check if painting should happen is right at the top of the method:

LayoutRect overflowRect(visualOverflowRect(lineTop, lineBottom));
overflowRect.inflate(renderer()->maximalOutlineSize(paintInfo.phase));
flipForWritingMode(overflowRect);
overflowRect.moveBy(paintOffset);

if (!paintInfo.rect.intersects(pixelSnappedIntRect(overflowRect)))
    return;

From this, we can glean two pieces of information, just like we did in the RenderBox example: that overflowRect defines our painted area, and that we should instrument after the if statement that determines if we should paint or not.

Looking at the rest of the method and the plethora of if and return statements, it is less obvious how far into the method our instrumentation code should go. All of those conditions might look very opaque, but you may be happy to know that you don’t need to understand them all to decide where to put the instrumentation code.

Most of the conditions in InlineFlowBox::paint have to do with the different phases of painting. I mentioned earlier that CSS defines the order in which painting should be done: WebKit uses paint phases to implement this. So all these if statements are doing is ensuring that only the proper things are drawn in a given phase. If we were writing production code, we would need to determine in which phase our outline should be drawn in, and make sure that it is only drawn in that phase. However, since this is exploratory code, we can just draw the outline in every phase, which will ensure that it gets shows up on top of any other content rendered by this object. The simplest way to do this is to place the instrumentation code as the first thing after it is determined that painting should happen.

Great! Now we know where the code should go, and we know which variable contains our bounding box, so we can take the code from earlier, changing overflowBox to overflowRect and changing the color to red just in case we want to have this active at the same time as the changes to RenderBlock:

Color color;
color.setRGB(255, 0, 0);
paintInfo.context->setStrokeColor(color, style()->colorSpace());
paintInfo.context->strokeRect(overflowRect, 2);

That’s the right direction, but if you do this, you will find out that it doesn’t compile: the compiler can’t find a style() method! That’s because we’ve discovered that InlineFlowBox is not a render object, it is a helper, used by render objects like RenderInline.

Luckily, these helper objects have a reference to their render object, accessible via the m_renderer instance variable. This allows us to make one more change to our code which will allow it to compile:

Color color;
color.setRGB(255, 0, 0);
paintInfo.context->setStrokeColor(color, m_renderer->style()->colorSpace());
paintInfo.context->strokeRect(overflowRect, 2);

And then you can see the InlineFlowBoxes in all their glory:

What’s next?

If you didn’t get a working build before reading the whole thing, I would suggest going back, setting up a build, and then trying out the code. It really is a great way to learn how layout (and even a bit of painting) works.

If you have a working build and were following along at home, you should try instrumenting the paint methods of some of the other classes in Source/WebCore/rendering (InlineBox and InlineTextBox are good places to start), and see how these classes map to the visual elements of a web page. You might be surprised by what you discover.

And if that isn’t enough for you, there are plenty of issues on bugs.webkit.org that you could dig into. (And if you can’t find something you find interesting there, I’m sure that someone on the #webkit channel on irc.freenode.net could give suggestions.) After all, there’s no better way to learn than to really work with the code.

Of course, I will be also writing more posts here as well. Stay tuned for my next post on WebKit’s layout tests and the infrastructure that runs them.

If I were to summarize the evolution of performance tests in WebKit, I’d starting with the early ages when we had JavaScript performance tests only for JavaScriptCore (SunSpider test suite) and we had another set of tests for V8 (V8 test suite). We also had a ton of layout tests, which could give performance feedback, but had purposes other than performance testing. You can say at this point: “Hey, stop! There are benchmark sites and suites all around online!” I totally agree with this, but we needed something more Web-Engine specific, something for testing WebKit itself (including the JavaScript engine and the Web engine) instead of the browser that is built above WebKit.

Let’s distinguish between online benchmarks for browser-level performance (e.g. Chromium performance testing) and the engine-level performance tests. Engine-level performance tests do not test the browser or the underlying platform’s graphical performance, they intend to test a part of a specific component of the web-engine (e.g. parse time of the HTML parser or runtime of the layout-system for floating containers). Browser-level performance tests usually do complex things that most likely try to use more components of the web-engine. Usually the goal is with these tests to reproduce some kind of real browsing behavior to measure the browser’s response time. This post is only about the engine-level testing.

Engine Level Performance Tests have been in WebKit trunk for more than a year now. We improved the system a lot in the last year (e.g. we added support for memory measurements in WebKit Bug #78984), so I think it is time to blog about it to a wider audience. Although work on the system is still in progress, it’s already capable both of demonstrating improvements or catching both performance and memory regressions.

In the first part of this entry, I want to give you a short introduction to the system and a short description how you can use the testing infrastructure. In the second part I intend to talk about the continuous performance measuring system and its online visualizer - the performance-test website. If you follow carefully I’m sure you get some information about our super-exciting future plans!

What is a performance test in WebKit?

Our performance tests measure the run-time performance and the memory usage of WebKit. In all the test cases we start the measurement before the concrete test (the function, the animation, the page loading) starts and stop it when it finishes. Although measuring performance and memory sound pretty straightforward, it can be deceptively difficult. For example, what do we mean by run-time performance? The right answer depends on the test itself. The animation performance-tests produce frame per second values (fps). The tests that measure the runtime of different JS functions (DOM manipulation, page loading, etc.) can produce either milliseconds (ms) or runs per second (run/s). If we really want to understand the meaning of a specific set of performance measurements, we need to look deeper at the actual test cases, but that’s not goal of this post. C’mon, this is just an introduction!

The memory consumption tests produce two values. The first one is the general heap usage of WebKit (memory allocated through the FastMalloc interface) and the second is the heap usage of JavaScript (memory allocated by the actual JavaScript engine). We count all of our raw memory results in bytes, but as you will see it later on the result pages, we display them in kilobytes.

Both the performance and the memory results are produced via the JavaScript engine. All of our performance-tests are JavaScript-based except the Webpage Replay Tests (you can read about them on the related page in WebKit trac). We experimented with other approaches like C++ and Python, but the JavaScript one was the most general over the different WebKit ports, so we stayed with it.

How to run performance tests in WebKit?

It’s time do some actual experiments! We have a script to run performance tests, it is located under the trunk/Tools/Scripts directory called run-perf-tests. I assume you have a WebKit build (if you don’t have a WebKit build, there is a documentation how to set one up), so to run all performance tests (located under trunk/PerformanceTests) you only need to run that script (different ports require additional parameters, for the details check out the –platform parameter). Because running all the tests can take long time, you can restrict the number of the tests run by specifying some directories or a list of tests as a parameter for run-perf-tests.

The script produces pretty straightforward output:

Running Bindings/set-attribute.html (18 of 115)
DESCRIPTION: This benchmark covers 'setAttribute' in Dromaeo/dom-attr.html and
             other DOM methods that return an undefined.
RESULT Bindings: set-attribute= 670.696533834 runs/s
median= 670.967741935 runs/s, stdev= 4.72565174943 runs/s, 
        min= 663.265306122 runs/s, max= 677.966101695 runs/s
RESULT Bindings: set-attribute: JSHeap= 57804.8 bytes
median= 57832.0 bytes, stdev= 1283.97383151 bytes, 
        min= 54112.0 bytes, max= 59296.0 bytes
RESULT Bindings: set-attribute: Malloc= 1574148.0 bytes
median= 1572772.0 bytes, stdev= 3346.56713349 bytes, 
        min= 1568992.0 bytes, max= 1584504.0 bytes
Finished: 16.537399 s

The output contains all the things that we are interested in, like test names, descriptions (if they exist) and the performance and memory results. By default after the warm-up run, we run each test 20 times (DumpRenderTree / WebKitTestRunner) to provide a stable result.

After the script has finished the testing, in addition to the console output we get a nice HTML based table with all of our results. The results in the table show the average values and their deviation for each test. If the result is not stable enough we also get a nice sign.

It’s possible to switch between the Time and the Memory view and reorder the results. If we are interested in a specific test, we can select it to see more details, as the screenshot below.

How to compare performance results?

Let’s see a simple workflow: we have a clean WebKit repository with a build. We run all the performance-tests and we want to compare the results with our modified WebKit. Since we store all the performance results by default in the WebKitBuild/Release/PerformanceTestsResults.json file, it’s very simple to compare the results… You just need to apply your patch to the repository, rebuild WebKit and run performance-tests again. After the rerun, the results HTML page contains a new column and shows all the new and old results in the same table. You can repeat the measurement as many times as you wish, each run will add a new column to your results. Additionally, you can use compare different repositories or specify another file for storing the results. You can find additional details if you run the run-perf-tests –help command.

This way you can easily test the effect of your changes. Furthermore the results table will inform you about your improvements and regressions in a simple and clear way.

Continuous performance and memory results online

Each platform has its own performance bot (build.webkit.org) that provides continuous performance measurements and test results are submitted to ​http://webkit-perf.appspot.com/.

I think the most useful feature of the Perf-O-Matic system is the Custom Charts section. With the help of Custom Charts, we are able to make custom queries to check out, compare, and investigate individual test results that run on the performance bots in the past. This way we can verify improvements or catch regressions on the individual test level. See below for an example test evaluating CSS property setters and getters by setting all the possible CSS properties to a pre-defined value and access properties through JavaScript.

You can find several useful pieces of information in the chart above. We always want to know the name of the test, the port that we have tested, the difference to the previous measurement, the SVN revision and the date of the measurement. All of this information is located on a nice zoomable chart. Take some time to play with the charts, I’m pretty sure that you will also find it useful. We are planning to update this system to a newer version soon, so more useful features are coming!

Looking into the future of performance measurements

After we further stabilize the continuous performance testing system (WebKit Bug #77037) and we can identify a well-defined set of tests with low deviation and meaningful results (WebKit Bug #105003), we are planning to add a performance-testing Early Warning System support to Bugzilla. The system will report the possible performance and memory regressions for the uploaded patches automatically in a Bugzilla comment, so it will work just like the build/layout Early Warning System. It will help to improve the quality of our developments in WebKit a lot. It sounds cool, doesn’t it?

I hope you enjoyed this little introduction to the WebKit Performance Test system and its online visualizer, and that you will try some of these tools.

Links

Out of this challenge grew the desire to do make it less challenging for others, and help my learning process at the same time. I’ve found that the best way to learn something is to explain it to someone else, so I am beginning a series of posts about learning WebKit and WebKit layout. This first post will focus on the basics and pointers to documentation that has helped me along the way. Note that I assume that you have a working knowledge of HTML, CSS, and JavaScript. I also assume that you have a knowledge of C languages, as WebKit itself is written in C++. You shouldn’t need any great knowledge of C++ to follow along, but you will definitely need to learn C++ if you want to contribute to the code.

What is WebKit?

The first thing that may stump a beginner is quite simply the definition of WebKit itself. WebKit is not a browser, it is a rendering engine. Web browsers use a rendering engine to translate from the code that is written by developers into the visual representation familiar to end users. WebKit is used in many different browsers, from Chrome and Safari to the Playstation 3.

In order to support all of these platforms, the WebKit code base is separated into platform dependent code and platform independent code. Things like reading HTML and CSS, executing JavaScript, and figuring out where different elements should be drawn on the screen (layout) are shared between all of the platforms. However, things like networking and drawing on the screen are implemented differently for each platform (or “port” in WebKit speak), because each platform has its own way of doing these things.

WebKit is further separated into components for different functions:

WebKit is not only the name of the entire project, it is also the name of the API that’s used by browsers and other applications. There is a second version of this API, called WebKit2, which was developed to bring multi-process capabilities to WebKit. JavaScriptCore is the JavaScript engine that comes with WebKit, but many browsers replace it with their own implementations. The part of the system responsible for layout is WebCore, which also covers everything to do with CSS, HTML, the DOM, rendering, and more. All of these are built on top of WTF (Web Template Framework), which is a utility library containing things like common data structures and threading primitives.

What is Layout?

When WebKit consumes a web page, it generates a DOM tree from the HTML source. The details of how this is done are outside the scope of this post, but there is an excellent article that describes the general workings and data structures behind both WebKit and Gecko and is highly recommended reading. The task of layout is to examine the DOM tree and determine the size and position of all of the elements so that the rendering step can then draw them.

Understanding the rules of layout

Unfortunately, the mechanics of layout are much too complex to summarize here. The current standard rules for laying out content are defined in the CSS 2.1 Specification, but that can be very hard to understand for the uninitiated. Both Web Platform Docs and Mozilla Developer Network have more accessible descriptions of the rules for layout. Most of what is in these documents should be familiar to seasoned web developers, as it is impossible to get a web site to behave the way you want without understanding how things will get placed on the page. While these are not a substitute for reading the spec if you are a browser implementer, being familiar with the concepts makes the spec much easier to read.

The W3C (the organization that defines many of the standards for the web) acknowledges that the CSS standard can be hard to read, and provides a helpful guide to reading the CSS specifications. The most important sections of the spec for a developer working in WebKit’s layout engine are Box model, Visual formatting model, and Visual formatting model details. Many of the variable and function names in WebKit’s layout code are taken straight out of the specification, so knowing the terminology can greatly help with understanding the system.

As you get more into the layout code, you will find things that are not specified in CSS 2.1, as WebKit has already started implementing features from CSS 3. Unlike CSS 2.1, CSS 3 isn’t a single specification, as it has been broken into modules for each feature area. The modules are all versioned independently, so there isn’t really a canonical list of what makes up CSS 3. The CSS current work page at the W3C is a very good place to see what the latest status of the specifications are.

How is layout done in WebKit?

While understanding the other parts of the spec are very useful, once you have an understanding of the CSS Box Model, you should be able to dive in and understand much of the layout code.

I said earlier that layout is done on the DOM tree, which isn’t entirely true. Before starting layout, a tree of render objects is created. Most DOM elements get corresponding render objects, but some special ones like head and elements with display: none don’t have renderers, since they have no visual representation. Also, some elements get more than one renderer. For example, when text must be wrapped to fit into the width of its container, a new render object is created for each line, even though there is only one DOM element for the run of text. The following diagram shows a simplified version of the render tree and it’s relation to the DOM tree:

The layout process is managed by the FrameView C++ class, which can start layout from the root of the render object tree (a full layout), or from a subtree (a partial layout). Full layout is the most common, as partial layout can only be done when it is certain that laying out the subtree cannot affect any elements that are not part of that subtree. For example, partial layout is used for when text fields are updated by the user typing in new text.

Regardless of if a full or partial layout is initiated, once the layout method is called on the renderer at the root of the tree (or subtree), it follows this recursive algorithm:

1. The current renderer computes its width.
2. For each child, the current renderer:
   1. Determines the position of the child.
   2. Asks the child to compute its dimensions.
3. The current renderer computes its height.

Of course there are exceptions and special cases to this, which are as complex as the rules for layout themselves. For much more detail, you should read the render tree construction and the layout sections of How Browsers Work.

Once the layout process has finished, the tree can then be drawn. Each render object has a paint method to accomplish this, but that’s no longer layout and thus outside of the scope of this post.

That’s great, but how does this match up with the code?

It can be a bit dangerous to give links to specific parts of the WebKit code base, as it changes so rapidly that the links are soon out of date. Thus, I will stick to generalizations here. The C++ classes that make up the DOM tree live under Source/WebCore/dom, while the render classes live in Source/WebCore/rendering. Instead of duplicating what has already been written, I will defer to Dave Hyatt’s blog post on Layout and Rendering Basics for a list of the major C++ classes that are used in the layout process. The links in his post are broken, but the names of the classes and the files that contain them are the same. (You can look in the directories I mentioned above for the classes, or just insert “Source/” in the URLs between “trunk/” and “WebCore/”.)

The basics article is the first in a series of blog posts that Dave Hyatt wrote about WebKit layout. They are a bit old and incomplete, but are one of the most useful sources of information about WebKit layout.

I would be remiss if I didn’t mention Eric Seidel’s talk on rendering in WebKit. It is of more recent vintage than Hyatt’s blog posts, and packs a lot of knowledge into a 30 minute presentation.

What now?

If that didn’t give you enough reading, I’ll be following up with a post on a way to visualize which render classes are responsible for which parts of the page. After that, I intend to cover layout tests and DumpRenderTree. And you’ll just have to stay tuned to find out what happens after that! I’ll be sure to update this post with links to the future posts in this series.

Links

There are a lot of links in this article, so here’s a section listing the important ones for your convenience.

• Arun Patole’s blog post on WebKit documentation. This is an amazingly comprehensive list of WebKit documentation, and not just for layout.
• How Browsers Work: comprehensive explanation of the workings of both WebKit and Gecko.
• Dave Hyatt’s Layout Blogs: Layout and rendering explained by the master.
• Eric Seidel’s talk on WebKit rendering: More on layout and rendering by an expert in a 30 minute talk.
• CSS 2.1 Specification: The definition on how layout should work.

Photo Filter Demo

It is possible to combine these filter functions in interesting ways to simulate complex photo filter effects.  You can extend the visuals even further by layering the same element at varying opacity with different filters applied.  We used a combination of filter functions to create a Photo Filter demo that we showcased at The Create The Web event in SF. This demo is now available on GitHub.

Here is what we used to create an Old-Style photo effect:

filter: sepia(0.8) saturate(3) brightness(0.25) contrast(2);

Before

After

You can use many other built-in filter effects in tandem. The available built-in filters are:

• grayscale
• sepia
• saturate
• brightness
• contrast
• opacity
• invert
• hue-rotate
• blur
• drop-shadow

Take a look at our code to find many ways these functions can be used to create complex photo filters. You can also read more about the built-in filters and their values in the specification.

As built-in CSS Filters are already available in Chrome, Safari, & Mobile Safari on iOS, you can start playing with them today and see how they can be used to enhance your web application. The CSS FilterLab is a great resource to play with filters and instantly see the results.

Have you been playing with Filter effects? Please do share your code samples with us in the comments!

If you have code that used the regionLayoutUpdate event, note that the capitalization of this event has changed to regionlayoutupdate to match other DOM Level 3 events like mouseover and compositionupdate. The event in the latest WebKit builds is now webkitregionlayoutupdate, a change tracked in WebKit bug 100355. If your code using the event suddenly stops working with a new WebKit build, this is likely the culprit.

And remember the CSS Regions functionality remains behind a run-time flag.

Between September 22nd and September 24th the Adobe WebKit team in Bucharest organized and hosted an European WebKit hackathon.

Why a WebKit hackathon?

And an European one for that, you might ask. Well, there are a couple of reasons, having to do with both building code and building communities.

Open source projects, more than “closed” projects, need to have at their core a community of people that know, understand and respect each other – technically and, to some extent, personally, too. While it’s possible to meet and be part of the community via the Internet, sometimes direct, face to face interaction can go a long way in helping to understand each other’s position, interests and opinions as well as their skills and areas of expertise.

As such, a WebKit hackathon proved to be the perfect environment for contributing to WebKit – both in terms of code but also in terms of better understanding the contributions and interests of different contributing entities, be it companies or individuals. Hacking sessions were interspersed with presentations and talks about different on-going efforts – ranging from “administrative” tasks to ongoing specification efforts and less common use-cases for WebKit.

European webkittens

With more than 25 people expressing interest in the hackathon, in the end 20 people attended the event – a mix of developers from Intel, Samsung USA, Igalia (Spain) and the University of Szeged (Hungary) and Adobe employees from US and Romania.
The first day debuted with presentations by each team about their work in WebKit and their areas of interest for the rest of the hackathon. In alphabetical order, here’s a brief description of each of these teams.

Adobe‘s current contributions are mainly around new CSS features and their implementation in WebKit – things like CSS Regions and Exclusions, CSS compositing, CSS filters and CSS transforms. There’s also some work around the Chromium Embedding Framework.

Igalia is a company based in Spain and the main contributors/maintainers of the GTK port, their main commercial work being consulting and helping other companies embed WebKitGTK in their products. They shared some interesting insights regarding WebKit development in China and India – apparently many companies are using WebKit and hacking on it and fixing bugs, but close to none contribute back to the trunk.

Intel is investing a lot in WebKit in the context of the EFL WebKit port that is built on Linux. Besides the EFL work, Intel also significantly contributes to other areas of WebKit and Chrome such as WebAudio, enabling Chromium on Android for the x86 architecture and improving the V8 JavaScript engine.

Samsung US is the other important contributor to the EFL port. They also have some interesting contributions around WebCL, working on both the spec and the implementation in WebKit. Igor showed us some nifty bits and pieces but apparently the best is yet to be announced.

The University of Szeged is an important contributor to the Qt WebKit port and the de facto gardeners for it (gardening means making sure the bots for a certain port are green and investigating/fixing issues/logging bugs and rolling out patches when they become red). They also have students working on WebKit for other companies, through different academic collaboration programs like sponsorships and internships. Given the academic environment they’re also involved in more “researchy” projects, mainly around JavaScript optimizations (in JavaScriptCore), parallel image decoding, memory usage instrumentation and optimization.

So what did we hack?

Once we got to know each other a little bit better through the aforementioned presentations, there came the tricky part of deciding what to hack on for the next two days. A number of topics were proposed and in the end three groups were created, focused around SVG & graphics, enabling CSS Regions on other ports and Web Inspector. The better part of the next two days was a mix of hacking, discussing approaches and ideas for the bugs we started on, a more in-depth look at Qt gardening and of course, fun and beer (in the evening!).

Saturday afternoon, before heading for a walk in the city, we had a demo session where everyone had the opportunity to present their work after the hackathon. Here are the highlights of this session:

SVG & graphics

Raul Hudea worked on WebKit bug #96381, enabling -webkit-clip-path to reference fragments inside an SVG document. Andrei Bucur did some similar work, enabling use of gradients defined in an SVG document as CSS masks (think -webkit-mask). Dirk Schultze decided to try something different (non-SVG ) and worked on a prototype implementation for the path object in the upcoming canvas specification.

Web Inspector

Mirela Budaes fixed bug #97120 that prevented a pop-out from closing when moving the mouse outside it in certain conditions. Andrei Poenaru, one of our summer interns, continued his great work on enabling CSS Regions support in Web Inspector by bringing the ability to highlight multiple elements at a time in the Elements panel one step closer to completion . As for myself, I worked on bug #91382, adding the ability to comment lines in the JavaScript source editor using the Cmd (Ctrl) + / keyboard shortcut.

CSS Regions on other ports

The team spent some time on figuring out exactly how to enable and disable features both at compile time and at runtime on the different ports. The good news is that on Qt, GTK and EFL with Regions enabled, most of the regions tests already pass. There are still issues around WebKit vs. WebKit 2 as different ports ship different flavors of WebKit by default. They also set up and configured a VM that can compile and run the Qt, GTK and EFL ports with Regions enabled – very useful for testing patches before hitting the bots.

Other hacks

Working somehow outside of the established teams, Horia Olaru prototyped an extension to the document DOM API, similar to document.elementFromPoint() but that actually returns all the elements at the given position, not just the top-most in z-order. Alex Chiculita added the last finishing touches to the CSS FilterLab while also landing a WebKit patch and helping other hackers with his WebKit experience and reviews.

What’s next?

This is the first European WebKit hackathon that Adobe has sponsored. Besides the actual hacking, it was good to see the amount of interaction, learning new things about others, and drafting common lines of actions. Going forward, we’re looking forward to repeating this event, hopefully with even more contributors from more companies interested in WebKit.
In the meanwhile, if you want to make the web better, and would fancy spending a couple of days with web gurus of all stripes in Beijing or Paris, be sure to check out the Test the Web Forward events.