WebKit Memory Tuning …

We do a fair amount of WebKit related work here at Crank. You rarely see our developers in the public eye because many of our ports to date have been to esoteric operating system, hardware platforms or custom graphics environments.

One of the areas we are frequently requested to assist in, is in the tailoring of a port to a particular set of performance contraints, usually CPU and memory usage. This is rarely straightforward as it involves an in-depth understanding of what trade-offs a customer is willing to make in terms of features and functionalities.

This week on the WebKit mailing list there was an interesting thread surrounding the ‘leaking of memory’ as perceived by a user who expected that if all the memory caches were turned off, that there should be no image resource maintained in memory. For WebKit, as it stands today, that is not a true statement. The discussion thread is a bit fragmented and the best way to follow it is to go here:


and search for the subject “Regarding cache memory leaks”.

The comments are enlightening, and demonstrate just what kind of work is required in order to curb the active memory consumption of WebKit based products.

We’ve done this kind of customization a few times now and are hoping that we will shortly be able to launch an embedded friendly WebKit platform that uses Storyboard as the UI/browser framework.


WebKit is everywhere … always a bit different

Interesting post about the multitude of varieties and flavours of WebKit that are available that is worth a read.

What is important to understand is the WebKit is an engine, it is not a browser.  Products take a snapshot of WebKit and then incorporate it into their own products with a specific set of features enabled (HTML5, SVG, Web Workers, Inspector, SQL db, …) and their own browser decorator or presentation functionality (ie Safari, Chrome, Iris, …) snapshot it, ship it and maintain it for as long as they need.

Here at Crank we have ported and optimized the WebKit engine over half a dozen times in order to accomadate different operating systems, CPU architectures and rendering technologies.  No two of our ports have been the same because our clients, mostly building embedded products, have very specific needs that we cater our WebKit customization efforts towards.  The needs of an in-car navigation system are different from those of a kitchen appliance which are different from those of a stereo receiver,  digital printer and camera.

WebKit offers a great technology baseline that can be readily customized and ported.  Some of those changes make it back into the baseline, others do not.  Given our experience with WebKit I’m not surprised by the diversity of experience.


Coming soon: WebKit for QNX

As I’ve posted before on the QNX development blog Send Receive Reply Crank has been working away for a couple of months now getting WebKit up and running in the QNX Neutrino 6.4.0 environment using the Advanced Graphics (AG) framework. 

It has been running well on x86 for several weeks now, but as always no source code that is supposed to be platform agnostic is ever as clean as it should be, so it took a few days of tinkering to get it up and running on all of the important architectures that QNX supports.  As much as WebKit is touted as being more “embedded friendly”, we still ended up spending a week doing some light tuning to improve its performance on lower end hardware (A note to QNX developers out there repetitive file open’s are not your friend … but more on that later).

We’ve got lots of ideas on how we can Crank up the performance of these browsers even further but for now, we’re excited about what we’ve brought to QNX Neutrino 6.4.0: A modern web browser framework (WebKit) running in a high performance graphics environment (AG) that runs on the four major processor families (x86, PowerPC (PPC), SuperH (SH), ARM) supported by QNX.

We’re working in conjunction with QNX to get a new WebBrowser project seeded into Foundry27, the QNX developer portal and will be making binaries available for users to try (in addition to our original Photon port).  However, in the meantime, if you are interested in integrating web browsing technology into your product and want to know more about how WebKit might work for you, give us a shout.

In case you were wondering what the platforms were were running on, here’s the list of which evaluation boards and platforms that we used for testing:

  • Jade (ARM)
  • Media 5200 (PPC)
  • Solution Engine 7751 (SH)
  • Intel Atom (x86)