From all those, I’m specially happy because we will be finally releasing the very first beta version of the new WebKit2GTK+ API, based in the multi-process architecture of WebKit2, as well as providing support for Accelerated Compositing and WebGL.

This new WebKit2GTK+ API, as you perhaps already know, will allow applications gain the split process model of WebKit2 out-of-the box, which is awesome. Xan already mentioned some of the advantages of it becoming beta for GNOME 3.6 in his last post this week, being my favorite ones the “increased responsiveness and stability” (quoting Xan) that will come with it, as well as the fact that it will be not only powerful enough to port old applications and write new ones, but also simpler and easier to use (we are putting a lot of effort on this).

And honestly, I think we are doing pretty well in that regard, even though there’s still a lot of work to do before we can release an stable version of this new API (due for WebKitGTK+ 2.0, to be released with GNOME 3.8), which will also mean the very first version of Epiphany that will be using WebKit2 by default.

With regard to Accelerated Compositing and WebGL, I’d just like to mention that having them supported in WebKitGTK+ from now on is great because it means you will be able to render visually stunning web content in your browser of choice (epiphany, huh?), as well as enjoy more subtle improvements such as smoother animations or increased responsivenes while browsing. You can visit this post by my mate Martin for more details on this topic.

Anyway, all these are very nice words and all that, but sometimes it’s not that easy to properly understand just with words what exactly those things will actually mean for users, so I decided to spend some time today polishing a bit the videos I used as demos in my talk during GUADEC, and link them from here, so everyone can easily watch them now.

@Eduard: At the moment the Pointer Lock API is not yet supported in WebKitGTK+, but I agree it would be a nice addition, and also a nice complement to all the new stuff that it’s coming with WebKit2GTK+, like AC or WebGL (I’m thinking of FPS games too here ;-)).

However, for the next cycle (towards GNOME 3.8) we are focused on porting and writing the APIs that we will need to make WebKit2GTK+ stable and mature enough for applications, like “Web”, to start using it “safely” (no API/ABI breaks) from that point on.

Which is a long way of saying that, as this API doesn’t fall in the category of things that we would need to port applications to WebKit2GTK+ (see [1]), it’s not likely it will get implemented in the next cycle, although the idea is to eventually add support for it after that.