Looks interesting, it could be done well with existing development tools for current platforms (i.e WPF, Cocoa) to have dirt simple cross-platform UI's.
At first by "embeddable browser" I thought that it would let you embed a web browser with javascript or with the embed HTML tag, but that's just my association with the word 'embed'
Not quite. What the project accomplishes is the ability to embed a fully functional and interactive web browser into another application (e.g. a game), with complete control over the pixels. Accomplishing the same functionality with a WebView, while theoretically possible, would be slow, clunky, and suffer from crashes (should the browser crash), as the rendering engine is running in the same process. It's my understanding that this will be rendered nearly obsolete with widespread Webkit2 adoption, but for now, it does provide a significant benefit (in terms of stability and usability) over a Cocoa WebView.
Seems interesting. Besides the fact that it is not open source, I'd like to know how it compares with Phantomjs: http://code.google.com/p/phantomjs/
Edit: Guess the most important difference is that Awesomium is embeddable gui browser, while Phantomjs is headless, more suited to using the browser as a library, and suited for programns to to browse the web, not users.
Not exactly-- awesomium can be used for both headless rendering and embedded GUI rendering. It outputs to a BGRA 32-bit pixel-buffer; it's the embedder's job to display it in their respective UI framework.
Btw, AwesomiumSharp has recently been re-written and now includes a drop-in WebControl component for WPF that you can hook up to your application with XAML. We're about to stage a major re-launch of the wrapper + new 1.6.2 SDK release in a couple days.
As far as I know we've never heard from the Awesomium developers; they don't mention which version of Chrome they're based on which makes me suspect they're not staying in sync with trunk.
That suspicion comes from the fact that the Chromium Embedded developer does participate in Chrome development -- to the extent that he keeps his project working -- and occasionally pops up on our mailing list discussing API changes that would benefit embedding.
PS: wonder whether the Awesomium people are doing the right thing by WebKit's LGPL license, hmm...
I'm the main Awesomium developer-- the 1.6 branch is based off a stable revision from April 2010.
We've recently updated to the latest Chromium trunk and will be launching an experimental, public build of our 1.7 branch soon. (Would have happened sooner but we've been focusing more on getting the library stable rather than absorbing new features.)
By the way, we do participate in the development of Chromium (albeit, rather covertly in IRC), I personally have been a long-time lurker of the mailing-list since the first month it opened. :-)
Regarding WebKit's (or, more specifically, WebCore's) LGPL license-- we've sought legal counsel on this and believe we've satisfied the conditions. We are, nonetheless, planning to package up WebKit into a separate dynamic library in the near future.
Hey, main developer of Awesomium here-- allow me to answer your question:
Awesomium 1.6 was designed from the ground up with the following goals in mind:
* Must render to a 32-bit BGRA pixel-buffer (most common image format)
* Must be absolutely windowless (to allow use in any context, 3D or otherwise)
* Must emulate Chrome's sandbox architecture (for security and crash isolation)
* Must support platform-agnostic input
* Must support Flash plugins on all platforms
* Must be flexible and easy to configure
* Must maintain a simple, easy-to-use API
Chromium Embedded Framework (CEF) is largely intended to be used by "embedding chromium browser windows" in your application. That's a key difference-- you're embedding a window inside of your application versus the more versatile pixel-buffer that our RenderBuffer class provides. This makes it nearly impossible to use inside a 3D graphics context or in other situations where embedding a native window handle is not feasible.
Additionally, CEF has a single-process architecture which means it does not scale as effectively nor isolate crashes in the manner that Awesomium or Chrome does (the Flash plugin can crash on a web-page in Awesomium-- as is liable to happen-- and your application will continue to run as normal).
I personally have been working on embedding WebKit, Mozilla Gecko, and similar technologies for nearly five years now so I've got a pretty good deal of experience on how to do it right. If you need any help, feel free to drop me at line at support@awesomium.com
very little conceptual difference. In practice however, Berkelium is really really immature. The API is much weaker, things like Flash may or may not work. The install is not as clean. I guess that's the difference between a small cost to a corporation vs free.
I realize that hobbyists would prefer free, but that's ok, since Berkelium is open enough that they can fix it.
We're actually getting ready to launch a massive update (1.6.2) to Awesomium in a couple days (new tutorials, new SDK, new .NET wrapper, new samples, etc.) Stay tuned. :-)
The project is based on the Quest3D engine, so a wrapper had to be written to expose Awesonium in the engine. The whole thing is open-sourced, so feel free to use the wrapper for your own Quest3D projects.
The biggest advantages that we found when using Awesonium as a GUI rendering system are the following:
- Support for highly interactive Flash GUI components. In fact, we embedded Flash videos/lessons directly in the game and let Awesonium do the rendering through its Flash plug-in.
- Seamless migration of the GUI content from the game's lesson browser to the internet. All HTML/Flash lessons can be accessed in the game as well as just online through a regular browser with no changes in the code.
18 comments
[ 2.6 ms ] story [ 61.5 ms ] threadAt first by "embeddable browser" I thought that it would let you embed a web browser with javascript or with the embed HTML tag, but that's just my association with the word 'embed'
http://doc.qt.nokia.com/latest/qwebview.html
Edit: Guess the most important difference is that Awesomium is embeddable gui browser, while Phantomjs is headless, more suited to using the browser as a library, and suited for programns to to browse the web, not users.
What's the main difference between this project and awesomium ?
Our .NET wrapper is open-source and up on GitHub: https://github.com/khrona/AwesomiumSharp
Btw, AwesomiumSharp has recently been re-written and now includes a drop-in WebControl component for WPF that you can hook up to your application with XAML. We're about to stage a major re-launch of the wrapper + new 1.6.2 SDK release in a couple days.
As far as I know we've never heard from the Awesomium developers; they don't mention which version of Chrome they're based on which makes me suspect they're not staying in sync with trunk.
That suspicion comes from the fact that the Chromium Embedded developer does participate in Chrome development -- to the extent that he keeps his project working -- and occasionally pops up on our mailing list discussing API changes that would benefit embedding.
PS: wonder whether the Awesomium people are doing the right thing by WebKit's LGPL license, hmm...
We've recently updated to the latest Chromium trunk and will be launching an experimental, public build of our 1.7 branch soon. (Would have happened sooner but we've been focusing more on getting the library stable rather than absorbing new features.)
By the way, we do participate in the development of Chromium (albeit, rather covertly in IRC), I personally have been a long-time lurker of the mailing-list since the first month it opened. :-)
Regarding WebKit's (or, more specifically, WebCore's) LGPL license-- we've sought legal counsel on this and believe we've satisfied the conditions. We are, nonetheless, planning to package up WebKit into a separate dynamic library in the near future.
Awesomium 1.6 was designed from the ground up with the following goals in mind:
* Must render to a 32-bit BGRA pixel-buffer (most common image format)
* Must be absolutely windowless (to allow use in any context, 3D or otherwise)
* Must emulate Chrome's sandbox architecture (for security and crash isolation)
* Must support platform-agnostic input
* Must support Flash plugins on all platforms
* Must be flexible and easy to configure
* Must maintain a simple, easy-to-use API
Chromium Embedded Framework (CEF) is largely intended to be used by "embedding chromium browser windows" in your application. That's a key difference-- you're embedding a window inside of your application versus the more versatile pixel-buffer that our RenderBuffer class provides. This makes it nearly impossible to use inside a 3D graphics context or in other situations where embedding a native window handle is not feasible.
Additionally, CEF has a single-process architecture which means it does not scale as effectively nor isolate crashes in the manner that Awesomium or Chrome does (the Flash plugin can crash on a web-page in Awesomium-- as is liable to happen-- and your application will continue to run as normal).
I personally have been working on embedding WebKit, Mozilla Gecko, and similar technologies for nearly five years now so I've got a pretty good deal of experience on how to do it right. If you need any help, feel free to drop me at line at support@awesomium.com
I realize that hobbyists would prefer free, but that's ok, since Berkelium is open enough that they can fix it.
We're actually getting ready to launch a massive update (1.6.2) to Awesomium in a couple days (new tutorials, new SDK, new .NET wrapper, new samples, etc.) Stay tuned. :-)
http://sourceforge.net/projects/learn-cnc-game/
The project is based on the Quest3D engine, so a wrapper had to be written to expose Awesonium in the engine. The whole thing is open-sourced, so feel free to use the wrapper for your own Quest3D projects.
The biggest advantages that we found when using Awesonium as a GUI rendering system are the following:
- Support for highly interactive Flash GUI components. In fact, we embedded Flash videos/lessons directly in the game and let Awesonium do the rendering through its Flash plug-in.
- Seamless migration of the GUI content from the game's lesson browser to the internet. All HTML/Flash lessons can be accessed in the game as well as just online through a regular browser with no changes in the code.