Alex Danilo on web.dev

WebAssembly Threads ready to try in Chrome 70

2018-10-29T00:00:00Z

WebAssembly (Wasm) enables compilation of code written in C++ and other languages to run on the web. One very useful feature of native applications is the ability to use threads - a primitive for parallel computation. Most C and C++ developers would be familiar with pthreads which is a standardized API for thread management in an application.

The WebAssembly Community Group has been working on bringing threads to the web to enable real multi-threaded applications. As part of this effort, V8 has implemented necessary support for threads in the WebAssembly engine, available through an Origin Trial. Origin Trials allow developers to experiment with new web features before they are fully standardized. This allows us to gather real-world feedback from intrepid developers, which is critical to validate and improve new features.

The Chrome 70 release supports threads for WebAssembly and we encourage interested developers to start using them and give us feedback.

Threads? What about Workers? #

Browsers have supported parallelism via Web Workers since 2012 in Chrome 4; in fact it's normal to hear terms like 'on the main thread' etc. However, Web Workers do not share mutable data between them, instead relying on message-passing for communication. In fact, Chrome allocates a new V8 engine for each of them (called isolates). Isolates share neither compiled code nor JavaScript objects, and thus they cannot share mutable data like pthreads.

WebAssembly threads, on the other hand, are threads that can share the same Wasm memory. The underlying storage of the shared memory is accomplished with a SharedArrayBuffer, a JavaScript primitive that allows sharing a single ArrayBuffer's contents concurrently between workers. Each WebAssembly thread runs in a Web Worker, but their shared Wasm memory allows them to work much like they do on native platforms. This means that the applications that use Wasm threads are responsible for managing access to the shared memory as in any traditional threaded application. There are many existing code libraries written in C or C++ that use pthreads, and those can be compiled to Wasm and run in true threaded mode, allowing more cores to work on the same data simultaneously.

A simple example #

Here's an example of a simple 'C' program that uses threads.

#include <pthread.h>
#include <stdio.h>

// Calculate Fibonacci numbers shared function
int fibonacci(int iterations) {
    int     val = 1;
    int     last = 0;

    if (iterations == 0) {
        return 0;
    }
    for (int i = 1; i < iterations; i++) {
        int     seq;

        seq = val + last;
        last = val;
        val = seq;
    }
    return val;
}
// Start function for the background thread
void *bg_func(void *arg) {
    int     *iter = (void *)arg;

    *iter = fibonacci(*iter);
    return arg;
}
// Foreground thread and main entry point
int main(int argc, char *argv[]) {
    int         fg_val = 54;
    int         bg_val = 42;
    pthread_t   bg_thread;

    // Create the background thread
    if (pthread_create(&bg_thread, NULL, bg_func, &bg_val)) {
        perror("Thread create failed");
        return 1;
    }
    // Calculate on the foreground thread
    fg_val = fibonacci(fg_val);
    // Wait for background thread to finish
    if (pthread_join(bg_thread, NULL)) {
        perror("Thread join failed");
        return 2;
    }
    // Show the result from background and foreground threads
    printf("Fib(42) is %d, Fib(6 * 9) is %d\n", bg_val, fg_val);

    return 0;
}

That code begins with the main() function which declares 2 variables fg_val and bg_val. There is also a function called fibonacci(), which will be called by both of the threads in this example. The main() function creates a background thread using pthread_create() whose task is to calculate the fibonacci number sequence value corresponding to the value of the bg_val variable. Meanwhile, the main() function running in the foreground thread calculates it for the fg_val variable. Once the background thread has completed running, the results are printed out.

Compile for thread support #

First, you should have the emscripten SDK installed, preferably version 1.38.11 or later. To build our example code with threads enabled for running in the browser, we need to pass a couple of extra flags to the emscripten emcc compiler. Our command line looks like this:

emcc -O2 -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=2 -o test.js test.c

The command line argument '-s USE_PTHREADS=1' turns on threading support for the compiled WebAssembly module and the argument '-s PTHREAD_POOL_SIZE=2' tells the compiler to generate a pool of two (2) threads.

When the program is run, under the hood it will load the WebAssembly module, create a Web Worker for each of the threads in the thread pool, share the module with each of the workers, in this case it's 2, and those will be used whenever a call to pthread_create() is made. Each worker instantiates the Wasm module with the same memory, allowing them to cooperate. V8's newest changes in 7.0 share the compiled native code of Wasm modules that are passed between workers, which allows even very large applications to scale to many workers. Note, it makes sense to make sure the thread pool size is equal to the maximum number of threads your application needs, or thread creation may fail. At the same time, if the thread pool size is too large, you'll be creating unnecessary Web Workers that'll sit around doing nothing but using memory.

How to try it out #

The quickest way to test out our WebAssembly module is to turn on the experimental WebAssembly threads support in Chrome 70 onwards. Navigate to the URL about://flags in your browser as shown below:

Next, find the experimental WebAssembly threads setting which looks like this:

Change the setting to Enabled as shown below, then restart your browser.

After the browser has restarted, we can try loading the threaded WebAssembly module with a minimal HTML page, containing just this content:

<!DOCTYPE html>
<html>
  <title>Threads test</title>
  <body>
    <script src="test.js"></script>
  </body>
</html>

To try this page, you'll need to run some form of web server and load it from your browser. That will cause the WebAssembly module to load and run. Opening DevTools shows us the output from the run, and you should see something like the output image below in the console:

Our WebAssembly program with threads has executed successfully! We'd encourage you to try out your own threaded application using the steps outlined above.

Testing in the field with an Origin Trial #

Trying out threads by turning on experimental flags in the browser is fine for development purposes, but if you'd like to test your application out in the field, you can do so with what's known as an origin trial.

Origin trials let you try out experimental features with your users by obtaining a testing token that's tied to your domain. You can then deploy your app and expect it to work in a browser that can support the feature you're testing (in this case Chrome 70 onwards). To obtain your own token to run an origin trial, use the application form here.

We've hosted our simple example above using an origin trial token, so you can try it out for yourself without needing to build anything.

If you want to see what 4 threads running in parallel can do for ASCII art, then you must take a look at this demo as well!

Give us feedback #

WebAssembly threads are an extremely useful new primitive for porting applications to the web. It's now possible to run C and C++ applications and libraries which require pthreads support in the WebAssembly environment.

We're looking for feedback from developers trying out this feature as it'll help inform the standardization process as well as validate its usefulness. The best way to send feedback is to report issues and/or get involved with the standardization process in the WebAssembly Community Group.

Extending the browser with WebAssembly

2018-08-22T00:00:00Z

One of the best things about WebAssembly is the ability experiment with new capabilities and implement new ideas before the browser ships those features natively (if at all). You can think of using WebAssembly this way as a high-performance polyfill mechanism, where you write your feature in C/C++ or Rust rather than JavaScript.

With a plethora of existing code available for porting, it's possible to do things in the browser that weren't viable until WebAssembly came along.

This article will walk through an example of how to take the existing AV1 video codec source code, build a wrapper for it, and try it out inside your browser and tips to help with building a test harness to debug the wrapper. Full source code for the example here is available at github.com/GoogleChromeLabs/wasm-av1 for reference.

Download one of these two 24fps test video files and try them on our built demo.

Choosing an interesting code-base #

For a number of years now, we've seen that a large percentage of traffic on the web consists of video data, Cisco estimates it as much as 80% in fact! Of course, browser vendors and video sites are hugely aware of the desire to reduce the data consumed by all this video content. The key to that, of course, is better compression, and as you'd expect there is a lot of research into next-generation video compression aimed at reducing the data burden of shipping video across the internet.

As it happens, the Alliance for Open Media has been working on a next generation video compression scheme called AV1 that promises to shrink video data size considerably. In the future, we'd expect browsers to ship native support for AV1, but luckily the source code for the compressor and decompressor are open source, which makes that an ideal candidate for trying to compile it into WebAssembly so we can experiment with it in the browser.

Adapting for use in the browser #

One of the first things we need to do to get this code into the browser is to get to know the existing code to understand what the API is like. When first looking at this code, two things stand out:

The source tree is built using a tool called cmake; and
There are a number of examples that all assume some kind of file-based interface.

All the examples that get built by default can be run on the command line, and that is likely to be true in many other code bases available in the community. So, the interface we're going to build to make it run in the browser could be useful for many other command line tools.

Using `cmake` to build the source code #

Fortunately, the AV1 authors have been experimenting with Emscripten, the SDK we're going to use to build our WebAssembly version. In the root of the AV1 repository, the file CMakeLists.txtcontains these build rules:

if(EMSCRIPTEN)
add_preproc_definition(_POSIX_SOURCE)
append_link_flag_to_target("inspect" "-s TOTAL_MEMORY=402653184")
append_link_flag_to_target("inspect" "-s MODULARIZE=1")
append_link_flag_to_target("inspect"
                            "-s EXPORT_NAME=\"\'DecoderModule\'\"")
append_link_flag_to_target("inspect" "--memory-init-file 0")

if("${CMAKE_BUILD_TYPE}" STREQUAL "")
    # Default to -O3 when no build type is specified.
    append_compiler_flag("-O3")
endif()
em_link_post_js(inspect "${AOM_ROOT}/tools/inspect-post.js")
endif()

The Emscripten toolchain can generate output in two formats, one is called asm.js and the other is WebAssembly. We'll be targeting WebAssembly as it produces smaller output and can run faster. These existing build rules are meant to compile an asm.js version of the library for use in an inspector application that's leveraged to look at the content of a video file. For our usage, we need WebAssembly output so we add these lines just before the closing endif()statement in the rules above.

# Force generation of Wasm instead of asm.js
append_link_flag_to_target("inspect" "-s WASM=1")
append_compiler_flag("-s WASM=1")

Building with cmake means first generating some Makefiles by running cmake itself, followed by running the command make which will perform the compilation step. Note, that since we are using Emscripten we need to use the Emscripten compiler toolchain rather than the default host compiler. That's achieved by using Emscripten.cmake which is part of the Emscripten SDK and passing it's path as a parameter to cmake itself. The command line below is what we use to generate the Makefiles:

cmake path/to/aom \
  -DENABLE_CCACHE=1 -DAOM_TARGET_CPU=generic -DENABLE_DOCS=0 \
  -DCONFIG_ACCOUNTING=1 -DCONFIG_INSPECTION=1 -DCONFIG_MULTITHREAD=0 \
  -DCONFIG_RUNTIME_CPU_DETECT=0 -DCONFIG_UNIT_TESTS=0
  -DCONFIG_WEBM_IO=0 \
  -DCMAKE_TOOLCHAIN_FILE=path/to/emsdk-portable/.../Emscripten.cmake

The parameter path/to/aom should be set to the full path of the location of the AV1 library source files. The path/to/emsdk-portable/…/Emscripten.cmake parameter needs to be set to the path for the Emscripten.cmake toolchain description file.

For convenience we use a shell script to locate that file:

#!/bin/sh
EMCC_LOC=`which emcc`
EMSDK_LOC=`echo $EMCC_LOC | sed 's?/emscripten/[0-9.]*/emcc??'`
EMCMAKE_LOC=`find $EMSDK_LOC -name Emscripten.cmake -print`
echo $EMCMAKE_LOC

If you look at the top-level Makefile for this project, you can see how that script is used to configure the build.

Now that all of the setup has been done, we simply call make which will build the entire source tree, including samples, but most importantly generate libaom.a which contains the video decoder compiled and ready for us to incorporate into our project.

Designing an API to interface to the library #

Once we've built our library, we need to work out how to interface with it to send compressed video data to it and then read back frames of video that we can display in the browser.

Taking a look inside the AV1 code tree, a good starting point is an example video decoder which can be found in the file [simple_decoder.c](https://aomedia.googlesource.com/aom/+/master/examples/simple_decoder.c). That decoder reads in an IVF file and decodes it into a series of images that represent the frames in the video.

We implement our interface in the source file [decode-av1.c](https://github.com/GoogleChromeLabs/wasm-av1/blob/master/decode-av1.c).

Since our browser can't read files from the file system, we need to design some form of interface that lets us abstract away our I/O so that we can build something similar to the example decoder to get data into our AV1 library.

On the command line, file I/O is what's known as a stream interface, so we can just define our own interface that looks like stream I/O and build whatever we like in the underlying implementation.

We define our interface as this:

DATA_Source *DS_open(const char *what);
size_t      DS_read(DATA_Source *ds,
                    unsigned char *buf, size_t bytes);
int         DS_empty(DATA_Source *ds);
void        DS_close(DATA_Source *ds);
// Helper function for blob support
void        DS_set_blob(DATA_Source *ds, void *buf, size_t len);

The open/read/empty/close functions look a lot like normal file I/O operations which allows us to map them easily onto file I/O for a command line application, or implement them some other way when run inside a browser. The DATA_Source type is opaque from the JavaScript side, and just serves to encapsulate the interface. Note, that building an API that closely follows file semantics makes it easy to reuse in many other code-bases that are intended to be used from a command line (e.g. diff, sed, etc.).

We also need to define a helper function called DS_set_blob that binds raw binary data to our stream I/O functions. This lets the blob be 'read' as if it's a stream (i.e. looking like a sequentially read file).

Our example implementation enables reading the passed in blob as if it was a sequentially read data source. The reference code can be found in the file blob-api.c, and the entire implementation is just this:

struct DATA_Source {
    void        *ds_Buf;
    size_t      ds_Len;
    size_t      ds_Pos;
};

DATA_Source *
DS_open(const char *what) {
    DATA_Source     *ds;

    ds = malloc(sizeof *ds);
    if (ds != NULL) {
        memset(ds, 0, sizeof *ds);
    }
    return ds;
}

size_t
DS_read(DATA_Source *ds, unsigned char *buf, size_t bytes) {
    if (DS_empty(ds) || buf == NULL) {
        return 0;
    }
    if (bytes > (ds->ds_Len - ds->ds_Pos)) {
        bytes = ds->ds_Len - ds->ds_Pos;
    }
    memcpy(buf, &ds->ds_Buf[ds->ds_Pos], bytes);
    ds->ds_Pos += bytes;

    return bytes;
}

int
DS_empty(DATA_Source *ds) {
    return ds->ds_Pos >= ds->ds_Len;
}

void
DS_close(DATA_Source *ds) {
    free(ds);
}

void
DS_set_blob(DATA_Source *ds, void *buf, size_t len) {
    ds->ds_Buf = buf;
    ds->ds_Len = len;
    ds->ds_Pos = 0;
}

Building a test harness to test outside the browser #

One of the best practices in software engineering is to build unit tests for code in conjunction with integration tests.

When building with WebAssembly in the browser, it makes sense to build some form of unit test for the interface to the code we're working with so we can debug outside of the browser and also be able to test out the interface we've built.

In this example we've been emulating a stream based API as the interface to the AV1 library. So, logically it makes sense to build a test harness that we can use to build a version of our API that runs on the command line and does actual file I/O under the hood by implementing the file I/O itself underneath our DATA_Source API.

The stream I/O code for our test harness is straightforward, and looks like this:

DATA_Source *
DS_open(const char *what) {
    return (DATA_Source *)fopen(what, "rb");
}

size_t
DS_read(DATA_Source *ds, unsigned char *buf, size_t bytes) {
    return fread(buf, 1, bytes, (FILE *)ds);
}

int
DS_empty(DATA_Source *ds) {
    return feof((FILE *)ds);
}

void
DS_close(DATA_Source *ds) {
    fclose((FILE *)ds);
}

By abstracting the stream interface we can build our WebAssembly module to use binary data blobs when in the browser, and interface to real files when we build the code to test from the command line. Our test harness code can be found in the example source file test.c.

Implementing a buffering mechanism for multiple video frames #

When playing back video, it's common practice to buffer a few frames to help with smoother playback. For our purposes we'll just implement a buffer of 10 frames of video, so we'll buffer 10 frames before we start playback. Then each time a frame is displayed, we'll try to decode another frame so we keep the buffer full. This approach makes sure frames are available in advance to help stop the video stuttering.

With our simple example, the entire compressed video is available to read, so the buffering isn't really needed. However, if we're to extend the source data interface to support streaming input from a server, then we need to have the buffering mechanism in place.

The code in decode-av1.c for reading frames of video data from the AV1 library and storing in the buffer as this:

void
AVX_Decoder_run(AVX_Decoder *ad) {
    ...
    // Try to decode an image from the compressed stream, and buffer
    while (ad->ad_NumBuffered < NUM_FRAMES_BUFFERED) {
        ad->ad_Image = aom_codec_get_frame(&ad->ad_Codec,
                                           &ad->ad_Iterator);
        if (ad->ad_Image == NULL) {
            break;
        }
        else {
            buffer_frame(ad);
        }
    }

We've chosen to make the buffer contain 10 frames of video, which is just an arbitrary choice. Buffering more frames means more waiting time for the video to begin playback, whilst buffering too few frames can cause stalling during playback. In a native browser implementation, buffering of frames is far more complex than this implementation.

Getting the video frames onto the page with WebGL #

The frames of video that we've buffered need to be displayed on our page. Since this is dynamic video content, we want to be able to do that as fast as possible. For that, we turn to WebGL.

WebGL lets us take an image, such as a frame of video, and use it as a texture that gets painted on to some geometry. In the WebGL world, everything consists of triangles. So, for our case we can use a convenient built in feature of WebGL, called gl.TRIANGLE_FAN.

However, there is a minor problem. WebGL textures are supposed to be RGB images, one byte per color channel. The output from our AV1 decoder is images in a so-called YUV format, where the default output has 16 bits per channel, and also each U or V value corresponds to 4 pixels in the actual output image. This all means we need to color convert the image before we can pass it to WebGL for display.

To do so, we implement a function AVX_YUV_to_RGB() which you can find in the source file yuv-to-rgb.c. That function converts the output from the AV1 decoder into something we can pass to WebGL. Note, that when we call this function from JavaScript we need to make sure that the memory we're writing the converted image into has been allocated inside the WebAssembly module's memory - otherwise it can't get access to it. The function to get an image out from the WebAssembly module and paint it to the screen is this:

function show_frame(af) {
    if (rgb_image != 0) {
        // Convert The 16-bit YUV to 8-bit RGB
        let buf = Module._AVX_Video_Frame_get_buffer(af);
        Module._AVX_YUV_to_RGB(rgb_image, buf, WIDTH, HEIGHT);
        // Paint the image onto the canvas
        drawImageToCanvas(new Uint8Array(Module.HEAPU8.buffer,
                rgb_image, 3 * WIDTH * HEIGHT), WIDTH, HEIGHT);
    }
}

The drawImageToCanvas() function that implements the WebGL painting can be found in the source file draw-image.js for reference.

Future work and takeaways #

Trying our demo out on two test video files (recorded as 24 f.p.s. video) teaches us a few things:

It's entirely feasible to build a complex code-base to run performantly in the browser using WebAssembly; and
Something as CPU intensive as advanced video decoding is feasible via WebAssembly.

There are some limitations though: the implementation is all running on the main thread and we interleave painting and video decoding on that single thread. Offloading the decoding into a web worker could provide us with smoother playback, as the time to decode frames is highly dependent on the content of that frame and can sometimes take more time than we have budgeted.

The compilation into WebAssembly uses the AV1 configuration for a generic CPU type. If we compile natively on the command line for a generic CPU we see similar CPU load to decode the video as with the WebAssembly version, however the AV1 decoder library also includes SIMD implementations that run up to 5 times faster. The WebAssembly Community Group is currently working on extending the standard to include SIMD primitives, and when that comes along it promises to speed up decoding considerably. When that happens, it'll be entirely feasible to decode 4k HD video in real-time from a WebAssembly video decoder.

In any case, the example code is useful as a guide to help port any existing command line utility to run as a WebAssembly module and shows what's possible on the web already today.

Credits #

Thanks to Jeff Posnick, Eric Bidelman and Thomas Steiner for providing valuable review and feedback.

User timing API

2014-01-21T00:00:00Z

High performance web applications are crucial to a great user experience. As web applications become more and more complex, understanding performance impact is vital to creating a compelling experience. Over the past few years, a number of different APIs have appeared in the browser to help analyse performance of the network, load times, etc. but these don’t necessarily give fine-grained detail with sufficient flexibility to find what’s slowing down your application. Enter the User Timing API which provides a mechanism you can use to instrument your web application to identify where your application is spending its time. In this article we’ll cover the API plus examples of how to use it.

You can’t optimize what you can’t measure #

The first step in speeding up a slow web application is working out where time is being spent. Measuring the time impact of areas of Javascript code is the ideal way to identify hot spots, which is the first step in finding how to improve performance. Fortunately the User Timing API provides a way that you can insert API calls at different parts of your Javascript and then extract detailed timing data that can be used to help you optimize.

High Resolution time and `now()` #

A fundamental part of accurate time measurement is precision. In the old days we had timing based around millisecond measurement which is OK, but building a jank-free 60 FPS site means each frame needs to be drawn in 16ms. So when you only have millisecond accuracy it lacks the precision needed for good analysis. Enter High Resolution Time, a new timing type that’s built into modern browsers. High Resolution Time gives us floating point time stamps that can be accurate to microsecond resolution - a thousand times better than before.

To get the current time in your web application, call the now() method which forms an extension of the Performance interface. The following code shows how to do that:

var myTime = window.performance.now();

There is another interface called PerformanceTiming which provides a number of different times related to how your web application is loaded. The now() method returns the time elapsed from when the navigationStarttime in PerformanceTiming happened.

The DOMHighResTimeStamp type #

When trying to time web applications in the past you’d use something like Date.now() which returns a DOMTimeStamp. DOMTimeStamp returns an integer number of milliseconds as its value. In order to provide the higher accuracy needed for High Resolution time, a new type called DOMHighResTimeStamp was introduced. This type is a floating point value that also returns the time in milliseconds. But since it’s floating point, the value can represent fractional milliseconds, and so can yield an accuracy of one thousandth of a millisecond.

The User Timing Interface #

So now that we have high resolution time stamps, let’s use the User Timing interface to pull out timing information.

The User Timing interface provides functions that let us call methods at different places in our application that can provide a Hansel and Gretel style breadcrumb trail to let us track where the time is being spent.

Using `mark()` #

The mark() method is the main tool in our timing analysis toolkit. What mark() does is store a time stamp for us. What’s super useful about mark() is that we can name the time stamp, and the API will remember the name and the time stamp as a single unit.

Calling mark() at various places in your application lets you work out how much time it took you hit that ‘mark’ in your web application.

The specification calls out a number of suggested names for marks that might be interesting and are fairly self explanatory, such as mark_fully_loaded, mark_fully_visible,mark_above_the_fold, etc.

For example, we could set a mark for when the application is fully loaded by using the following code:

window.performance.mark('mark_fully_loaded');

By setting named marks throughout our web application we can gather a whole bunch of timing data and analyze it at our leisure to work out what the application is doing and when.

Calculating measurements with `measure()` #

Once you’ve set a bunch of timing marks, you’ll want to find out the elapsed time between them. You use the measure() method to do that.

The measure() method calculates the elapsed time between marks, and can also measure the time between your mark and any of the well-known event names in the PerformanceTiming interface.

For example, you could work out the time from the DOM being complete until your application state is fully loaded by using code like:

window.performance.measure('measure_load_from_dom', 'domComplete', 'mark_fully_loaded');

When you call measure() it stores the result independent of the marks you set, so you can retrieve them later. By storing away times as your application runs, the application remains responsive, and you can dump all the data out after your application has finished some work so it can be analyzed later.

Discarding marks with `clearMarks()` #

Sometimes it’s useful to be able to get rid of a bunch of marks that you’ve set up. For example, you might do batch runs on your web application and so you want to start fresh each run.

It’s easy enough to get rid of any marks you’ve set up by calling clearMarks().

So the example code below would blow away all the existing marks you have, so that you can set up a timing run again if you want.

window.performance.clearMarks();

Of course, there are some scenarios where you might not want to clear all of your marks. So if you want to get rid of specific marks, you can just pass the name of the mark you want to remove. For example, the code below:

window.peformance.clearMarks('mark_fully_loaded');

gets rid of the mark we set in the first example while leaving any other marks we set unchanged.

You might want to get rid of any measures you’ve made as well, and there’s a corresponding method to do that called clearMeasures(). It works exactly the same as clearMarks() does, but instead working on any measurements you’ve made. For example, the code:

window.performance.clearMeasures('measure_load_from_dom');

will remove the measure we made in the above measure() example. If you want to remove all measures, it works just the same as clearMarks() - in that you just call clearMeasures() without arguments.

Getting the timing data out #

It’s all well and good to set marks and measure intervals, but at some point you want to get at that timing data to perform some analysis. This is really simple too, all you have to do is use the PerformanceTimeline interface.

For example, the getEntriesByType() method lets us get all our mark times, or all of our measure times out as a list so we can iterate over it and digest the data. What’s nice is that the list gets returned in chronological order, so you can see the marks in the order they were hit in your web application.

The code below:

var items = window.performance.getEntriesByType('mark');

returns us a list of all the marks that have been hit in our web application, whilst the code:

var items = window.performance.getEntriesByType('measure');

returns us a list of all the measures we’ve made.

You can also get back a list of entries by using the specific name you’ve given them. So for example, the code:

var items = window.performance.getEntriesByName('mark_fully_loaded');

would return us a list with one item in it containing the ‘mark_fully_loaded’ time stamp in the startTime property.

Timing an XHR request (example) #

Now that we have a decent picture of the User Timing API we can use it to analyze how long all our XMLHttpRequests take in our web application.

First we’ll modify all of our send() requests to issue a function call that sets up the marks, and at the same time change our success callbacks with a function call that sets another mark and then generates a measure of how long the request took.

So normally our XMLHttpRequest would look something like:

var myReq = new XMLHttpRequest();
myReq.open('GET', url, true);
myReq.onload = function(e) {
  do_something(e.responseText);
}
myReq.send();

For our example we’ll add a global counter to track the number of requests and also to use it to store a measure for each request that’s made. The code to do this looks like:

var reqCnt = 0;

var myReq = new XMLHttpRequest();
myReq.open('GET', url, true);
myReq.onload = function(e) {
  window.performance.mark('mark_end_xhr');
  reqCnt++;
  window.performance.measure('measure_xhr_' + reqCnt, 'mark_start_xhr', 'mark_end_xhr');
  do_something(e.responseText);
}
window.performance.mark('mark_start_xhr');
myReq.send();

The code above generates a measure with a unique name value for every XMLHttpRequest we send. We’re assuming the requests run in sequence - the code for parallel requests would need to be a bit more complex to handle requests that return out of order, we’ll leave that as an exercise for the reader.

Once the web application has done a bunch of requests we could dump them all to the console using the code below:

var items = window.performance.getEntriesByType('measure');
for (var i = 0; i &lt; items.length; ++i) {
  var req = items[i];
  console.log('XHR ' + req.name + ' took ' + req.duration + 'ms');
}

Conclusion #

The User Timing API gives you a lot of great tools to apply to any aspect of your web application. Narrowing down the hot-spots in your application can be easily achieved by sprinkling API calls throughout your web application and post-processing the timing data generated to create a clear picture of where time is being spent. But what if your browser doesn’t support this API? No problem, you can find a great polyfill here that emulates the API really well and plays nicely with webpagetest.org as well. So what are you waiting for? Try out the User Timing API on your applications now, you’ll work out how to speed them up and your users will thank you for making their experience so much better.

Splash vector graphics on your responsive site

2012-10-15T00:00:00Z

Creating mobile content that dazzles means balancing the amount of data downloaded against maximal visual impact. Vector graphics are a great way to deliver stunning visual results using minimal bandwidth.

Many people think of canvas as the only way to draw a mixture of vectors and rasters on the web, but there are alternatives that have some advantages. A great way to achieve vector drawing is through the use of Scalable Vector Graphics (SVG) which is a key part of HTML5.

We all know responsive design is a big part of handling varying screen sizes, and SVG is ideal for handling different size screens with ease.

SVG is a great way to present vector based line drawings and is a great complement to bitmaps, the latter being better suited for continuous tone images.

One of the most useful things about SVG is that it’s resolution independent, meaning that you don’t need to think about how many pixels you have on your device, the result will always scale and be optimized by the browser to look great.

Popular authoring tools like the Drawing application in Google Drive, Inkscape, Illustrator, Corel Draw and lots of others generate SVG so there are lots of ways to generate content. We'll dive into some ways to use SVG assets, plus some optimization tips to get you going.

Scaling fundamentals #

Let's start with a simple scenario - you want a full page graphic to be the background of your web page. It'd be really useful to have your company logo, or anything like that full-screen in the background at all times, but of course that's super hard to do nicely with all the different screen sizes out there. So to illustrate, we'll start with the humble HTML5 logo.

The HTML5 logo is shown below - and you guessed it, it originates as an SVG file.

Click on the logo and take a look at it in any modern browser and you'll see that it scales beautifully to any size window. Try opening it up in your favorite browser, resize the window and observe that the image is crisp at any magnification. If we were to try that with a bitmap image, we'd either have to serve many different sizes for each screen we could encounter, or be forced to put up with horribly pixelated scaled images.

So what's the big deal? Well if you hadn't noticed, this is the only format that scales independently of the device we're using to look at it with. So we only need to serve one asset to our users, without ever needing to know what their screen or window size is - neat!

But wait, there's more - the HTML5 logo is just 1427 bytes! Yikes, that's so small that it will hardly dent any mobile data plan when loading it, which makes it fast to load and that makes it cheap and fast for your users!

Another nice thing about SVG files is that they can be GZIP compressed to further shrink them. When you compress SVG that way, the file extension has to be changed to ‘.svgz’. In the case of the HTML5 logo, it shrinks to just 663 bytes when compressed - and most modern browsers handle it with ease!

With our example file on some of the latest devices we see something like a 60x advantage using compressed vector data! Also, note that these comparisons are being made between the JPEG and the SVG, rather than PNG. However, the JPEG is a lossy format which results in lower quality than either the SVG or PNG. If we were to use PNG, the advantage would be over 80x which is astounding!

But of course PNG and JPEG are not created equal. A number of optimization tips tell you to use JPEG instead of PNG, but that's not always such a great idea. Take a look at the images below. The image on the left is a PNG image of the top right part of the HTML5 logo enlarged 6x. The image on the right is the same thing but encoded with JPEG.

PNG image

JPEG image

It's easy to see that the file size saving in JPEG comes at a cost, with color artifacts at the sharp edges - probably making your retina think it needs glasses:-) To be fair, JPEG is optimized for photos, and that's why it's not as good for vector art. In any case, the SVG version is the same as the PNG in quality so wins on all accounts - both file size and clarity.

Making Vector Backgrounds #

Lets take a look at how you could use a vector file as the background of a page. One easy way is to declare your background file using CSS fixed positioning:

<style>
#bg {
  position:fixed; 
  top:0; 
  left:0; 
  width:100%;
  z-index: -1;
}
</style>
<img src="HTML5-logo.svgz" id="bg" alt="HTML5 logo"></pre>

You'll notice that no matter what the size of the display, the image is sized nicely with crisp clean edges.

Then of course, we'd like to put some content over the background.

But as you can see, the result is less than ideal since we can't read the text. So what do we do?

Adjusting the background to look nicer #

The obvious thing we need to do is make all the color in the background image be lighter. This is easily achieved by use of the CSS opacity property - or using opacity in the SVG file itself. You could make this work by simply adding this code to your CSS content:

#bg {
  opacity: 0.2;
}

That would give you a result like so:

This solution whilst easy, is likely to be a performance pain point on a mobile device. For most existing mobile browsers, use of the opacity property can be a lot slower to draw with compared with opaque objects.

A better solution #

Modifying the color in the original SVG content is far better than setting opacity with CSS. Here is our HTML5 logo modified to look faded out by changing the colors used, and in the process avoiding the opacity property altogether. So the background image below looks identical to the result from changing the opacity, but will actually paint a lot faster and save us CPU time and save precious battery life in the process.

So now we have a decent grasp of some fundamentals, let's move on to some other features.

Using Gradients Efficiently #

Let's say we want to build a button. We could start by creating a rectangle with nice rounded corners. Then we could add a nice linear gradient to give the button some nice texture. The code to do so could look something like:

<svg xmlns="http://www.w3.org/2000/svg">
  <defs>
    <linearGradient id="blueshiny">
      <stop stop-color="#a0caf6" offset="0"/>
      <stop stop-color="#1579df" offset="0.5" />
      <stop stop-color="#1675d6" offset="0.5"/>
      <stop stop-color="#115ca9" offset="1"/>
    </linearGradient>
  </defs>
  <g id="button" onclick="alert('ouch!');">
    <rect fill="url(#blueshiny)" width="198" height="83" x="3" y="4" rx="15" />
    <text x="100" y="55" fill="white" font-size="18pt" text-anchor="middle">Press me</text>
  </g>
</svg>

The resultant button would end up with something like this:

Notice how the gradient we've added goes from left to right. This is the default gradient direction in SVG. But we can do better, for a couple of different reasons: aesthetics and performance. Let's try to change the gradient direction to make it look a bit nicer. Setting the 'x1', 'y1', 'x2', and 'y2' attributes on the linear gradient controls the direction of the fill color.

Setting just the 'y2' attribute lets us change the gradient to be diagonal. So this small code change:

<linearGradient id="blueshiny" y2="1">

gives us a different look for our button, it ends up looking like the image below.

We can also easily change the gradient to go from top to bottom with this small code change:

<linearGradient id="blueshiny" x2="0" y2="1">

and that ends up looking like the image below.

So what's with all the discussion about different angles of the gradient I hear you ask?

Well it turns out that the last example - the one with the gradient running from top to bottom is the fastest to draw on most devices. It's a very little known secret amongst the graphic geeks who write browser code that vertical (top to bottom) gradients paint almost as fast as a solid color. (The reason is that painting an object is done in horizontal lines down the page - and the guts of the drawing code understand that the color doesn't change across each line, and so they optimize it).

So when you choose to use gradients in your page design, vertical gradients will be faster and use less battery as a side effect. This speedup applies to CSS gradients as well, so it's not just an SVG thing.

If we feel really adventurous with this new gradient knowledge, then we can perhaps add a cool gradient behind our HTML5 logo by adding the code below:

<defs>
<linearGradient id="grad1" x2="0" y2="1">
    <stop stop-color="#FBE6FB" offset="0" />
    <stop stop-color="#CCCCFF" offset="0.2" />
    <stop stop-color="#CCFFCC" offset="0.4" />
    <stop stop-color="#FFFFCC" offset="0.6" />
    <stop stop-color="#FFEDCC" offset="0.8" />
    <stop stop-color="#FFCCCC" offset="1" />
</linearGradient>
</defs>
<rect x="-200" y="-160" width="910" height="830" fill="url(#grad1)"/></pre>

The code above adds a faded vertical linear gradient to the backgound of our HTML5 logo to give a subtle multi-color tinge that runs fast - as fast as a solid color background.

If you load the content in a desktop browser and resize to extreme aspect ratios, you'll see white bars appear at the top/bottom or left/right sides. Anyway, after the code changes made above the resultant background will look like this:

Animate With Ease #

By now you might be wondering what's the point of using an SVG gradient as the backdrop for your page. Indeed it might make sense to do that with CSS gradients, but one advantage of SVG is that the gradient itself lives in the DOM. This means that you can modify it with script, but more importantly you can take advantage of SVG's built in animation capability to add subtle changes to your content.

As an example, we'll modify our colorful HTML5 logo by changing the linear gradient definition to the code below:

<linearGradient id="grad1" x2="0" y2="1">
    <stop stop-color="#FBE6FB" offset="0">
    <animate attributeName="stop-color"
        values="#FBE6FB;#CCCCFF;#CCFFCC;#FFFFCC;#FFEDCC;#FFCCCC;#FBE6FB"
        begin="0s" dur="20s" repeatCount="indefinite"/>
    </stop>
    <stop stop-color="#CCCCFF" offset="0.2">
    <animate attributeName="stop-color"
        values="#CCCCFF;#CCFFCC;#FFFFCC;#FFEDCC;#FFCCCC;#FBE6FB;#CCCCFF"
        begin="0s" dur="20s" repeatCount="indefinite"/>
    </stop>
    <stop stop-color="#CCFFCC" offset="0.4">
    <animate attributeName="stop-color"
        values="#CCFFCC;#FFFFCC;#FFEDCC;#FFCCCC;#FBE6FB;#CCCCFF;#CCFFCC"
        begin="0s" dur="20s" repeatCount="indefinite"/>
    </stop>
    <stop stop-color="#FFFFCC" offset="0.6">
    <animate attributeName="stop-color"
        values="#FFFFCC;#FFEDCC;#FFCCCC;#FBE6FB;#CCCCFF;#CCFFCC;#FFFFCC"
        begin="0s" dur="20s" repeatCount="indefinite"/>
    </stop>
    <stop stop-color="#FFEDCC" offset="0.8">
    <animate attributeName="stop-color"
        values="#FFEDCC;#FFCCCC;#FBE6FB;#CCCCFF;#CCFFCC;#FFFFCC;#FFEDCC"
        begin="0s" dur="20s" repeatCount="indefinite"/>
    </stop>
    <stop stop-color="#FFCCCC" offset="1">
    <animate attributeName="stop-color"
        values="#FFCCCC;#FBE6FB;#CCCCFF;#CCFFCC;#FFFFCC;#FFEDCC;#FFCCCC"
        begin="0s" dur="20s" repeatCount="indefinite"/>
    </stop>
</linearGradient>

Take a look at the image below to see the result of these changes above.

The code is changing the colors of our linear gradient through all the different color stops we've defined in a continuous cycle that takes 20 seconds to run. The effect of that is that the gradient looks like it's moving up the page in a continuous motion that never stops.

The beauty of this is that there's no script required! That's why it runs as a referenced image from this page, but also it reduces workload on a mobile CPU by removing the need for script.

Also, the browser itself can take advantage of its knowledge of the painting to ensure minimal CPU overhead is used to do the fancy animation.

There is one caveat: some browsers don't handle this style of animation at all, but in that case you'll still get a nice colored background but it just won't change - this could be worked around by using script (and requestAnimationFrame) but that's a bit beyond this article.

One more thing to note, is that this uncompressed SVG file is only 2922 bytes - incredibly small to supply such a rich graphics effect, keeping your users and those data plans happy in the process.

Where to from here? #

There are many cases where SVG is less than ideal, photos and videos being better represented in other formats. Text is another one, where native HTML and CSS work much better in general. However, as a tool in the arsenal for line drawn artwork it can be the ideal choice.

We've touched on a few basic fundamental uses for SVG graphics, showing how easy it is to generate tiny content that provides full screen vivid graphics with a minimal amount of download. Small enhancements to the content can create amazing graphical results easily with trivial amounts of markup. In the next article we'll explore some more details about how the animation built into SVG can be used for more simple and powerful effects and compare the use of canvas with SVG to choose the right tool for authoring your mobile graphics site.

Other good resources #

Inkscape an open source drawing application that uses SVG as its file format.
Open Clip Art a huge open source clip art library containing thousands of SVG images.
W3C SVG Page containing links to specifications, resources, etc.
Raphaël a Javascript library that provides a convenient API to draw and animate SVG content with great fallback for older browsers.
SVG Resources from Slippery Rock University - includes a link to a great SVG Primer.

Understanding CSS filter effects

2012-05-25T00:00:00Z

Introduction #

Filters are a powerful tool that web authors can use to achieve interesting visual effects. In this article we’ll cover the history of filter effects, what they do and how to use them. We’ll cover examples of all the predefined filters defined for CSS with some examples. We’ll also cover performance considerations for using them on desktop and mobile devices since knowing the speed impact of filters is important for a good user experience. Finally we’ll review the current state of implementation in modern browsers.

The past, present and future of filter effects #

Filter effects originated as part of the Scalable Vector Graphics (SVG) specification. They were created to apply a number of different pixel based image effects to a vector drawing. Over time as browser vendors added SVG capabilities into their browsers, the usefulness of filters became evident. Robert O’Callahan from Mozilla came up with the brilliant idea of using SVG filters through the application of CSS to ‘normal’ HTML content. Robert prototyped an early version that showed how powerful the combination of filters and CSS styling could be. The CSS and SVG working groups in the W3C decided to harmonize the use of filters for both HTML and SVG via CSS styling, and thus the ‘filter’ property for CSS was born. Right now a joint task force of people working on CSS and SVG is doing a ton of work to make filters universally useful. You can find the current specification for all this stuff here.

A new life for the ‘filter’ CSS property #

Deja Vu sometimes strikes a web developer when seeing ‘filter’ in CSS styles. This is due to the fact that old versions of Internet Explorer had a ‘filter’ property exposed via CSS to perform some platform specific functionality. This has been deprecated in favor of the standard ‘filter’ property which is now part of CSS3. So when you see ‘filter’ out in the wild on some old web pages, there’s no need to be confused. The new ‘filter’ property is where all the action is, and new versions of IE are implementing it just the same as all modern browsers.

How filters work #

So what does a filter do exactly? The easiest way to think of a filter is as a post processing step that does something magical after all your page content has been laid out and drawn.

When a browser loads a web page it needs to apply styles, perform layout and then render the page so there's something to look at. Filters kick in after all those steps and just before the page is copied to the screen. What they do is take a snapshot of the rendered page as a bitmap image, then perform some graphics magic on the pixels in the snapshot and then draw the result over the top of the original page image. One way to think of them is like a filter placed on the front of a camera lens. What you’re seeing through the lens is the outside world modified by the effect of the filter.

This of course means that there's time consumed when drawing a page with filters on it, but using them properly will have minimal impact on the speed of your site.

Also, just as you can stack a number of filters in front of each other on your camera lens, you can apply an arbitrary number of filters one after the other to achieve all sorts of effects.

Filters defined using SVG and CSS #

Since filters originally came from SVG there are different ways to define and use them. SVG itself has a <filter> element that wraps up definitions of various filter effects using XML syntax. The set of filters defined by CSS take advantage of the same graphics model, but they are much simpler definitions that are easy to use in a style sheet.

Most of the CSS filters can be expressed in terms of SVG filters, and CSS also allows you to reference a filter specified in SVG if you want. The CSS filter designers have taken great pains to make the application of a filter easier for web authors, and so this article will just cover the filters available directly from CSS, ignoring the SVG definitions for the time being.

How to apply a CSS filter #

Using filters from CSS is done by using the ‘filter’ property applied to any visible element on your web page. For a very simple example you could write something like

div { { % mixin filter: grayscale(100%); % } }

and that would make the content inside all <div>elements on the page turn gray. Great for making your page look like a TV image from the 1940s.

Original image.

Grayscale filtered image.

Most filters take some form of parameter to control how much filtering is done. So for example if you wanted to style your content to be half way between the original color and a grayscale version you’d do it like this:

div { { % mixin filter: grayscale(50%); % } }

Original image above but 50% gray filtered.

If you want to apply a number of different filters one after another, it’s easy - just place them in order in your CSS like so:

div { { % mixin filter: grayscale(100%) sepia(100%); % } }

That example will first make all the original color grayscale and then apply a sepia effect, and would end up looking like:

With the flexibility available for applying filters one after the other, all sorts of effects can be achieved - it’s totally up to your imagination to experiment with creating amazing results.

What filters effects are available using CSS #

So the original SVG filter mechanism is both powerful but at the same time can be daunting to use. Because of that, CSS introduces a bunch of standard filter effects that make using them really easy.

Let’s take a look at each of them and see what they do.

grayscale(amount): This converts color in our input image to a shade of gray. The ‘amount’ applied controls how much gray conversion is applied. If it’s 100% then everything will be a shade of gray, if it’s 0% the colors are unchanged. You can use a floating point number here if you prefer it over percentages, i.e. 0 works the same as 0% whilst 1.0 works the same as 100%.

Original

grayscale(100%)

sepia(amount): This gives the colors passed in a sepia tinge like in old photographs. The ‘amount’ applied works in the same way as for the ‘grayscale’ filter - namely 100% makes all the colors completely sepia toned and smaller values allow the effect to be applied in smaller proportions.

Original

sepia(100%)

saturate(amount): This applies a color saturation effect to the colors which makes them look more vivid. It’s a cool effect that can make photos look like posters or cartoons.This effect also allows you to use a value greater than 100% to really emphasize the saturation. Definitely an effect that can make things look pretty funky!

Original

saturate(10)

hue-rotate(angle): This one is a bit of a color geek effect that can be used for interesting results. What it does is shift the colors around to make an input image look completely different. If you can imagine a color spectrum going from red to violet around a color wheel, then this effect takes the original color on the wheel as input and rotates it by the ‘angle’ parameter to produce the color on the wheel to which it rotated as the output color value. So all the colors in the image are shifted by the same 'angle' on the wheel. This is of course a simplification of what it does, but hopefully close enough that it makes sense.

Original

hue-rotate(90deg)

invert(amount): This effect flips the colors - so that if the ‘amount’ applied is 100% the output looks like a photo negative back from the old film days of cameras! Just like before, using values smaller than 100% will progressively apply the invert effect.

Original

invert(100%)

opacity(amount): If you want the content being filtered to look semi-transparent, this is the one for you. The ‘amount’ value defines how opaque the output will be. So a value of 100% is completely opaque so the output will be exactly the same as the input. As the value drops below 100% the output image will become less opaque (more transparent) and you’ll see less and less of it. This of course means if it overlaps something else on the page, the stuff underneath will start to become visible. An ‘amount’ of 0% means it will completely disappear - but note, you can still get events like mouse clicks etc. to happen on completely transparent objects so this is handy if you want to create clickable areas without displaying anything.

This works the same as the ‘opacity’ property you already know. In general the CSS ‘opacity’ property isn’t hardware accelerated, but some browsers that implement filters using hardware acceleration will accelerate the filter version of opacity for much better performance.

Original

opacity(50%)

brightness(amount): This is just like the brightness control on your TV. It adjusts the colors between completely black and the original color in proportion to the ‘amount’ parameter. If you set this one to 0% you’ll see nothing but black, but as the value goes up towards 100% you see more and more of the original image brightening up, until you hit 100% where it’s the same as the input image. Of course you can just keep going - so setting something like 200% will make the image twice as bright as the original - great for adjusting those low light shots!

Original

brightness(140%)

contrast(amount): More controls from your TV set! This will adjust the difference between the darkest and lightest parts of the input image. If you use 0% you end up with black just like with ‘brightness’, so not too interesting. However as you increase the value towards 100% the difference in darkness changes until you hit 100% and it’s the original image again. You can also go beyond 100% for this effect too, which increases the difference between light and dark colors even more.

Original

contrast(200%)

blur(radius): If you want a soft edge for your content, you can add a blur. This one looks like the classic Vaseline on a sheet of glass look that used to be a popular movie making technique. It smudges all the colors together and spreads their effect out - kind of like when your eyes are out of focus. The ‘radius’ parameter affects how many pixels on the screen blend into each other, so a larger value will create more blur. Zero of course leaves the image unchanged.

Original

blur(10px)

drop-shadow(shadow): It’s so nice to be able to make your content look like it’s outside in the sun with a shadow on the ground behind it, and that of course is what ‘drop-shadow’ does. It takes a snapshot of the image, makes it a single color, blurs it, then offsets the result a bit so it looks like a shadow of the original content. The ‘shadow’ parameter passed in is a bit more complicated than just a single value. It is a series of values separated by a space - and some values are optional too! The ‘shadow’ values control where the shadow is placed, how much blur is applied, the color of the shadow, etc. For full details of what the ‘shadow’ values do, the CSS3 Backgrounds specification defines ‘box-shadow’ in great detail. A few examples below should give you a decent idea of what the various possibilities are.

drop-shadow(16px 16px 20px black)

drop-shadow(10px -16px 30px purple)

This is another filter operation that is similar to existing CSS functionality available via the ‘box-shadow’ property. Using the filter approach means that it may get hardware accelerated by some browsers as we described for the ‘opacity’ operation above.

url referencing SVG filters: Since filters originated as part of SVG, it’s only logical that you should be able to style your content using an SVG filter. This is easy with the current ‘filter’ property proposal. All filters in SVG are defined with an ‘id’ attribute that can be used to reference the filter effect. So, to use any SVG filter from CSS all you need to do is reference it using the ‘url’ syntax.

For example, the SVG markup for a filter could be something like:

<filter id="foo">...</filter>

then from CSS you could do something as simple as:

div { { % mixin filter: url(#foo); % } }

and voila! All the <div>s in your document will be styled with the SVG filter definitions.

custom (coming soon): Coming soon on the horizon are custom filters. These tap into the power of your graphics GPU to use a special shading language to perform amazing effects bounded only by your own imagination. This part of the ‘filter’ specification is still under discussion and in flux, but as soon as this starts to come to a browser near you, we’ll be sure to write more about what is possible.

Performance considerations #

One thing that every web developer cares about is performance of their web page or application. CSS filters are a powerful tool for visual effects, but at the same time might have an impact on the performance of your site.

Understanding what they do and how this affects performance matters, especially if you want your site to work well on mobile devices if they support CSS filters.

Firstly, not all filters are created equal! In fact, most filters will run really quickly on any platform and have very minor performance impact. However, filters that do any kind of blurring tend to be slower than the others. This of course means ‘blur’ and ‘drop-shadow’. This doesn’t mean you shouldn’t use them but understanding how they work might help.

When you do a blur, it mixes the colors from pixels all around the output pixel to generate a blurred result. So, say if your radius parameter is 2, then the filter needs to look at 2 pixels in every direction around each output pixel to generate the mixed color. This happens for each output pixel, so that means a lot of calculations that just get bigger when you increase the radius. Since blur looks in every direction, doubling the ‘radius’ means you need to look at 4 times as many pixels so in fact it’s 4 times slower for each doubling of the radius. The drop-shadow filter contains a blur as part of its effect, so it too behaves just like blur when you change the radius and spread parts of the shadow parameter.

All is not lost with blur since on some platforms it’s possible to use the GPU to accelerate it, but that’s not necessarily going to be available in every browser. When in doubt the best thing is to experiment with the ‘radius’ that gives you the effect you want, then try to reduce it as much as possible while still maintaining an acceptable visual effect. Tuning this way will make your users happier especially if they use your site from a phone.

If you’re using url based filters that reference SVG filters, they can contain any arbitrary filter effect so be aware that they too could be slow, so try to make sure you know what the filter effect does and experiment on a mobile device to make sure the performance is OK.

Availability in modern browsers #

Right now a number of the CSS filter effects are being made available in WebKit based browsers and Mozilla. We expect to see them soon in Opera as well as IE10. As the specification is still under development, some browser vendors have implemented this stuff using vendor prefixes. So in WebKit you need to use -webkit-filter, in Mozilla you will need to use -moz-filter and keep your eye out for other browser implementations as they appear.

Not all browsers will support all filter effects right away, so your mileage will vary. Presently, the Mozilla browser supports only the filter: url() function - without the vendor prefix, as that implementation pre-dates the other effects functions.

We’ve summarized the CSS filter effects available in the various browsers below with rough performance indicators for when they’re implemented in software. Note, that a number of modern browsers are beginning to implement these in hardware (GPU accelerated). When these are built with GPU support, performance will be greatly improved for the slower effects. As usual, testing on different browsers is the best way to evaluate the performance.

Filter effect	Browser support	Performance
grayscale	Chrome	very fast
sepia	Chrome	very fast
saturate	Chrome	very fast
hue-rotate	Chrome	fast
invert	Chrome	very fast
opacity	Chrome	can be slow
brightness	Chrome	fast
contrast	Chrome	fast
blur	Chrome	slow unless accelerated
drop-shadow	Chrome	can be slow
url()	Chrome, Mozilla	Varies, fast to slow

Other good resources #

An awesome interactive abstract painting with filters application which lets you experiment and share your artwork Be sure to check out Eric Bidelman’s excellent interactive filter page A great tutorial about filters with examples The official W3C Filter Effects 1.0 draft specification http://dev.w3.org/fxtf/filters/ Example UI created using filters

Alex Danilo on web.dev

WebAssembly Threads ready to try in Chrome 70

Threads? What about Workers? #

A simple example #

Compile for thread support #

How to try it out #

Testing in the field with an Origin Trial #

Give us feedback #

Extending the browser with WebAssembly

Choosing an interesting code-base #

Adapting for use in the browser #

Using cmake to build the source code #

Designing an API to interface to the library #

Building a test harness to test outside the browser #

Implementing a buffering mechanism for multiple video frames #

Getting the video frames onto the page with WebGL #

Future work and takeaways #

Credits #

User timing API

You can’t optimize what you can’t measure #

High Resolution time and now() #

The DOMHighResTimeStamp type #

The User Timing Interface #

Using mark() #

Calculating measurements with measure() #

Discarding marks with clearMarks() #

Getting the timing data out #

Timing an XHR request (example) #

Conclusion #

Splash vector graphics on your responsive site

Scaling fundamentals #

Making Vector Backgrounds #

Adjusting the background to look nicer #

A better solution #

Using Gradients Efficiently #

Animate With Ease #

Where to from here? #

Other good resources #

Understanding CSS filter effects

Introduction #

The past, present and future of filter effects #

A new life for the ‘filter’ CSS property #

How filters work #

Filters defined using SVG and CSS #

How to apply a CSS filter #

What filters effects are available using CSS #

Performance considerations #

Availability in modern browsers #

Other good resources #

Using `cmake` to build the source code #

High Resolution time and `now()` #

Using `mark()` #

Calculating measurements with `measure()` #

Discarding marks with `clearMarks()` #