Skip navigation

First release!

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!

Awesomium and Javascript, sitting in a tree…

Despite being sick these past few days and my having to help put up part of our fence (we’re still missing big sections due to the hurricane), I was able to irk out some time to work on Javascript integration.

Obviously, if you plan to manipulate your embedded web content in any meaningful way (besides simple loading of pages/URL’s), you need a way to pass data and events to and from the page. I’ve implemented three methods to help achieve this:

Javascript execution

You can directly execute arbitrary strings of Javascript from the C++ API. For example:

myWebView->executeJavasript("document.body.bgColor = 'blue'");

This is obviously incredibly useful however there is a catch: you can only execute Javascript that interacts with the DOM (document-object-model) after the DOM has loaded. This can be circumvented by subscribing a listener to the WebView and handling your Javascript execution within ‘onFinishLoading’.

Client Properties

Javascript execution is pretty cool but when all you need to do is pass a few values to your page for initialization purposes, it’s just too much of a headache. That’s where ‘Client Properties’ comes in.

Basically, using WebView::setProperty, you are able to set a Javascript variable that will persist on that WebView (accessible via the ‘Client’ object from your page). You can then design your page to be initialized using these ‘Client properties’. For example:

myWebView->setProperty("message", "Hello world!");
myWebView->setProperty("secretNumber", 42);
myWebView->loadFile("coolPage.html");

and the contents of ‘coolPage.html’:

<html>
<body>
<h1>Welcome to my page</h2>
<p>
<script type='text/javascript'>
document.write(Client.message);
</script>
</p>
<p>The secret number is: <br/>
<script type='text/javascript'>
document.write(Client.secretNumber);
</script>
</p>
</body>
</html>

Client Callbacks

The above two methods are great for passing data from the application to the web page but we still need a way to pass events and data from the web page to the application.

To handle this, you may register named callbacks to receive notification of certain Javascript method calls from the Client object. For example:

void onLoginClick(const JSArguments& args)
{
// handle stuff here
}


myWebView->setCallback("loginClick", Callback(this, &MyApp::onLoginClick));


myWebView->loadFile("myPage.html");


then, you can invoke this callback from your page using Javascript:


Client.loginClick(username, password);



		
	
									

			


			
			
			

				

					
Awesomium– now with moar osm

					
				

				

					
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.



									

			


			
			
			

				

					
Turbulence

					
				

				

					
Well, we seemed to have survived Hurricane Ike.


Friday night, things were really quite calm: no rain, low wind, and a beautiful sunset. After all our preparations and anxiety, I was frankly a bit disappointed– and then, about 1:00 AM, sporadic gusts of winds began increasing in frequency and intensity. The winds continued swelling in their chaotic fury and by 2:30 AM, we had lost power. Huddled in our downstairs living room with flourescent lamps, blankets, and a radio, we tried to listen to the news over the howl of the wind.


The storm peaked around 5:00 AM– the sheer force of the wind was absolutely incredible: the rain was falling horizontal, large trees, some taller than our two-story house, were bending at 45 degree angles, the biggest gusts made the windows rattle and fences wail. I kept noticing large blue-green flashes across the sky, each one causing the dim glow of the clouds to fade recognizably– I later learned that these unearthly displays were fuses in the power lines igniting and expiring.


About four hours later, the worst of the storm was over. In the pale light of the morning, we could see the extent of the damage: leaves and shredded foliage covered the ground, large tree limbs, ripped from their source, lay broken in tumbled heaps, portions of our backyard fence had been torn and dismantled, shingles and other miscellaneous objects had been flung about the yard.


Nevertheless, we were quite grateful that the majority of our house had been spared from the storm’s malice. Others weren’t so lucky. Over the news, we heard that Galveston island, our favored vacation spot and where we had been only a few weeks prior for a quick respite, was submerged in water and had taken a heavy beating. Murdoch’s Pier, an ancient landmark as well as the gift shop where I had so recently purchased exotic shells and starfish to decorate my new apartment with, was now nothing more– it was raped, pillaged, destroyed.


A large majority of Southeast Texas, us included, were without power on Saturday. We had luckily put much of our perishables into a light freeze the day before and still had gas running to our stove and so we survived well enough. Late Saturday night, we had power restored– our area was part of the lucky few that had minimal damage to the lines; the majority of areas in Houston (and in Huntsville, where my apartment is) still lack power.


I’ve been spending the past few days helping with the cleanup– we’ve managed to cut, trim, and bundle a majority of the fallen tree limbs and destroyed fencing. We’re still waiting for the garbage crews to come to our area and haul the mess off our curb but I think we’re finally returning to a bit of normalcy.

									

			


			
			
			

				

					
Hurricane, hurrah

					
				

				

					
 


Hey guys, Awesomium is coming along nicely but it’s on the back-burner for now as I’m preparing for the immediate landfall of Hurricane Ike here in Houston.


 


Hurricane Ike - Friday 10am - Predicted Path
Hurricane Ike - Friday 10am - Predicted Path


 


It’s gonna be exciting!

									

			


			
			
			

				

					
Awesomium– update part deux

					
				

				

					
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!

									

			


			
			
			

				

					
Awesomium– quick update

					
				

				

					
Just a quick update:


Motivated by the support I received from my last post (thanks guys!), I stayed up late last night and fleshed out the majority of Awesomium’s API. As always, I’ve tried to keep it simple and intuitive (most similar to Astral). Also, the interface should be abstracted enough to allow easy porting to other platforms.


There is still one annoying bug I’ve been trying to squash: certain page content triggers the registration of some extended encodings which then causes an assertion within addToTextEncodingNameMap of textencodingregistry.cpp. It’s a non-critical debug assertion and execution will continue just fine without it (as it does in Release) but it makes debugging the library pretty annoying (having to click ‘continue’ a bunch of times during the first page load). I’m probably initializing something wrong (ICU, maybe?).


Anyways, I’m close to to an alpha-release– if you’re interested in early testing, it’ll require a full Windows build of Chromium.

									

			


			
			
			

				

					
Awesomium– Google Chrome hacked!

					
				

				

					
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~!

									

			


			
			
			

				

					
I christen thee…!

					
				

				

					
W00t, first post!


This blog is a place for me to rant, carry on, and generally talk about various things that amuse me.


Speakin’ of cool stuff, I’ve been hacking away at one of my older projects these past two days. It’s called “Player” (hah, I fail at creativity) and it’s basically an attempt to make a 3D online “world” demo. Nothing too ambitious, just the client/server basics– essentially a 3D chat room.


Anyways, I’m pretty much done with the major implementation: a user can login with a unique username, run around the terrain, and speak with other players. I neglected to implement 3d navigation (server-side, the world is just a 2D grid), pathfinding, fighting, leveling up, and all the other accoutrements for the sake of this being a demo but I’m still pretty happy with the result.


		
		


Technology used:


    

  • 3D Engine: Ogre3D
    • 

  • GUI: Hikari (my own Flash embedding layer)
    • 

  • Text Overlays: Canvas (my own super-efficient 2D rendering layer)
    • 

  • Networking: RakNet
    • 

  • Input: OIS
    • 



I recently replaced BetaGUI with Hikari because it seemed like a fun idea. It worked out pretty well methinks– I learned a new technology (Flash), squashed some bugs, and gave the demo a little style. It’s nothing compared to what Eeenmachine has put together for ZeroGear, but it’s something nonetheless.


Also, I felt like using Canvas– my super-fast 2D rendering layer for Ogre3D– for something and decided to use it to render the player titles/messages. I devised a little system that automatically updates the screen-space position of a title based on the position of its Ogre::MovableObject (in this case, the ninja-actors). The titles are totally anti-aliased/hinted/shadowed and scale through multiple font-sizes based on the distance the object is from the camera. As for performance, it’s excellent: the glyphs are pre-rendered at runtime, packed into a texture atlas, and the geometry (each glyph quad) is pooled.


I know there’s a bunch of users who are eager to start a MMO but have no idea where to start and so ultimately, I’m gonna clean up the code and release “Player” as an example project for the Ogre3D community. I’m also considering writing a series of tutorials on getting started with Ogre3D from scratch (without the Example framework or any other crutch). Hopefully my efforts will give someone a poke in the right direction.