Skip navigation

Tag Archives: embedding

Get it while it’s hot over at the download page!

Here’s an overview of the major changes since v0.5:

  • Support for Flash plugins
  • Enhanced rendering performance on multi-core machines
  • Support for mouse-wheel input (WebView::injectMouseWheel)
  • The ability to grab the contents of the current page as plain text (WebView::getContentAsText)
  • Refactoring of callbacks to use WebViewListener instead
Advertisements

The first official Awesomium SDK (v0.5) is out now for MSVC8! You can download it here.

The main header is “WebCore.h”, so include that to access the entirety of the API. Almost everything is documented using standard Javadoc commenting and so it should be pretty easy to understand (I’ll probably generate online docs later using Doxygen). If you need any tips on usage or an idea of how to embed Awesomium within your application, take a look at the ‘app’ project in the SVN source.

Good luck and have fun!

P.S., remember to copy over the ICU DLL (it’s in bin/common) into your executable’s directory as well. If you don’t, everything will probably still run however various operations (mostly text-input and unicode-related stuff) will most definitely fail, causing undefined behavior.

 

P.P.S., I’ve started a discussion group to discuss development/support of Awesomium, check it out here!

fancy awesomium logo

fancy awesomium logo

I’m very proud to announce the very first release of Awesomium!

Version: v0.5
License: LGPL
Platform: Windows & MSVC8 only (for now)
Demo: Download here *

* Try this alternative version if the demo instantly closes upon startup.

The source code is now online at its SVN repository. Please be aware that this release is really only for hardcore developers only– it lacks documentation and is a little tough gathering the necessary dependencies. Nevertheless, if you’re too impatient for an SDK release or just eager to start hacking at the source yourself, to build Awesomium you will need to first obtain Chromium and build it (I used a Sept. 6th revision so try to sync with that date). Then, check Awesomium out into the directory adjacent to your chromium distribution (the project assumes you’ve named your chromium folder “chromium”), open the solution, and compile the ‘Awesomium’ project. If you wish to build the demo (project ‘App’), you will need to have installed the Ogre3D SDK.

For the most part, this release is quite stable however I’m still working on a few issues, in no particular order: node memory leaks, support for transparent backgrounds, minor stall during a clipboard copy, and support for certain plugins.

I would write a much longer and more eloquent article detailing all of my thoughts about the current state and future plans of Awesomium but I’m frankly exhausted due to my pulling an all-nighter to get this release out. Anyways, I hope yall have fun trying out the demo and good luck to those who wish to try compiling it from source!

Okay, enough about the hurricane– let’s talk shop.

Last week, I was having some problems with keyboard input and random freezes during certain interactions. A little tracing found that a global timer was being instantiated and would greedily respawn itself during a single cycle of the browser’s message loop.

Me, in my brilliance (or rather, my unwillingness to spawn a separate thread), decided to kill the global timer every time we cycled through the message loop. This solved all of the hangs but it still didn’t fix keyboard input and caused some secondary problems (like utter failure of all Javascript timers).

It was then I realized that I couldn’t implement this thing correctly without dipping my toes into the deep, dark depths of multi-threaded programming. I needed to encapsulate the core and components of Awesomium within a separate thread, run a dedicated message loop within said thread, and handle inter-thread communication and synchronization.

It took me five days of banzai, headache-inducing coding to implement but I’m proud to declare that Awesomium is multi-threaded (and stable!). It was one of the most complex tasks I’ve ever achieved as a programmer but it’s so cool seeing both of my laptop’s cores work at the same time.

Despite the multi-threading, I still wasn’t able to get keyboard input working. I finally went code diving (about 2 hours of tracing) and realized that the problem was linked with some assertions about the unicode text encoding: as I had suspected earlier, ICU wasn’t being initialized correctly. Upon inspection of the ICU initialization source, it had seemed to be attempting to load a DLL that it had assumed would be in the working directory. I located the ICU DLL, copied it to my working directory and voila– keyboard input worked and the runtime text encoding assertions disappeared. Unfortunately, this means that my previous statement about the total dependency size was incorrect: the ICU DLL is about 8 MB and the Awesomium DLL (release) is about 7 MB, so together, that’s a total dependency size of about 15 MB. It’s not too bad I suppose– people who need the absolute tiniest dependency size can always gzip the DLL’s and load them at runtime.

But hooray! Almost everything critical now works and is pretty stable. Popup-widgets (such as drop-down combo-boxes) are now supported by compositing them with the main web-view texture. Event listeners are also implemented– you can currently receive notifications for the beginnings of navigations, title receptions, and finishing of loads. Dirty-rectangle optimization and querying for ‘dirty’ render state is implemented. The only other ‘big’ point left on my to-do list is support for Javascript evaluation/callbacks. Getting that working seems to be a little more tricky than I thought and so I may put it off for later.

Oh and yes, in true ninja style, I’ve written this latest post using Awesomium.

I pulled another late-night coding session and am happy to report that a majority of the functionality is finished:

  • Mouse input injection
  • Rendering to an arbitrary BGRA buffer
  • Callbacks for load events
  • Invalidation detection
  • Ability to load from URLs, local files, or HTML strings

After spending the past 10 hours testing Awesomium out within an Ogre3D context, I’m now even more confident that WebKit certainly trounces Mozilla Gecko in such a setting. For comparison:

Gecko:

  • Total size added to application: ~15 MB
  • Startup time: ~2 seconds

WebKit-Chromium-Awesomium:

  • Total size added to application: ~6.8 MB
  • Startup time: non-discernible, practically instant

Furthermore, the API is absolutely excellent (there’s so much great stuff, I don’t know what to expose!), it seems easier to port to other platforms, builds in much less time (by about an order of magnitude), and it just feels faster. I have yet to do any true performance benchmarks but I think I can predict the winner.

Anyways, I’ve still got some other things left that I want to finish up before the initial alpha release:

  • Keyboard input injection
  • Efficient rendering of invalidated areas (dirty-rectangling)
  • Javascript evaluation/binding

I’m shooting to get some code up in an SVN within the next two days, so stay tuned!

Okay, I simply had to write a new post about this because I’m way too excited about it.

Yeah well, a little backstory first– I’ve been hunting for an alternative to Mozilla Gecko to power NaviLibrary (it’s a little noodle I wrote that allows people to embed web content within their 3D applications). I wanted something that was a little faster, a little smaller, and cross-platform. WebKit seemed like a great choice– it had coherent API, strong developer base, and wasn’t as bloaty as Gecko– until I realized that it linked to some proprietary/non-redistributable stuff (CoreGraphics and CFNetwork dependencies made it off-limits for OSS library experiments).

I was keeping track of the WebKit Cairo port, hoping that it would someday fulfill my needs, when out of nowhere– Google Chrome was instantiated. The browser is kick-ass and will surely bring about a new Age of the Internet but when I heard they were using WebKit, I realized there was something way awesome-er about this news. Sure enough, they had made their own cross-platform port of WebKit and replaced the proprietary dependencies with some even cooler things (such as Skia for graphics and their game-changing V8 Javascript engine). I knew what I had to do.

I got the source and spent several days absorbing all I could about their codebase, its API, the linkage, etc. What I aimed to achieve was this: extract their port of WebKit (V8, Skia, and all), wrap it up into another library (specifically for use in a window-less context), and create an application that could load up a webpage and render it to memory.

After much finoodling (and 2000 unresolved externals later), I’ve accomplished phase 1 of my project ‘Awesomum’ (which is “omg, I was able to load a page and render it without crashing!”):

 

The API that Google put together is really quite kick-ass– it’s got support for injection of mouse/keyboard events, Javascript evaluation, invalidation callbacks, navigation callbacks, and best of all, it lets us do off-screen, selective rendering. I really can’t wait to finish wrapping this up completely and start playing around with it.

I’m running into a few problems with certain content right now (I’m still trying to fully replicate the correct initialization of the core)– but I’ve definitely made some tangible progress. I’ll keep yall posted with more as it happens~!