Web Apocrypha

This is a follow-up blog post of our announcement of TyGL - the 2D-accelerated GPU rendering port of WebKit.

We have been received lots of feedback about TyGL and we would like to thank you for all questions, suggestions and comments. As we promised lets get into some technical details.

We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher.

The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations.

It's been a while since I last (and actually first) posted about Fuzzinator. Now I think that I have enough new experiences worth sharing.

More than a year ago, when I started fuzzing, I was mostly focusing on mutation-based fuzzer technologies since they were easy to build and pretty effective. Having a nice error-prone test suite (e.g. LayoutTests) was the warrant for fresh new bugs. At least for a while.

What is ASM.JS?

Now that mobile computers and cloud services become part of our lives, more and more developers see the potential of the web and online applications. ASM.JS, a strict subset of JavaScript, is a technology that provides a way to achieve near native speed in browsers, without the need of any plugin or extension. It is also possible to cross-compile C/C++ programs to it and running them directly in your browser.

In this post we will compare the JavaScript and ASM.JS performance in different browsers, trying out various kinds of web applications and benchmarks.

For some time it has been possible to build and run QtWebKit on Linux using Google's V8 JavaScript engine instead of the default JavaScriptCore. I thought it would be good to see some numbers comparing the runtime performance of the two engines in the same environment and also measuring the performance of the browser bindings.

In this post I'll show you how to configure and compile a MinGW toolchain for cross-compilation on Linux, then how to build Qt using this toolchain and finally compile the Qt port of WebKit from trunk.

When I tried to cross compile QtWebKit for ARM-Linux, I didn't find any clear description, so I have decided to write a blogpost about it. It's not too hard, but if you have never done something like this, it can be a little bit confusing. In this post, I will describe this method in some simple steps.

There are a lot of make specifications in Qt, but none of them is suitable for RVCT compilation. So, if you want to compile QtWebKit with RVCT, you have two options: either you create a new specification or you can use an existing one with wrapper scripts. In this post I'll describe the second option.

WebKitGtk+ cross compilation consists of two parts. First, you need a cross compiler and the library dependencies of WebKitGtk+. Next, you have to setup the build system properly. You can reach this with some wrapper scripts.

If we would like to build WebKitGTK+ for ARM platform, Scratchbox could be a good choice. In this post I will show, how we can install and setup Scratchbox to build WebKitGTK+. First, we have to install the Scratchbox and its ARM target. Next, we install some libraries to WebKitGTK+.
Let's see how we can do that.