adamkhrona

This is good: it's totally insecure to pass auth credentials in plain-text URLs.

Same here, as a developer of a cross-platform library, this is the only configuration that works for us. By restricting virtualization of OSX, Apple has effectively forced most developers to use this configuration.

Hey guys, thanks for the interest in our library!

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. :-)

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 [email protected]

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.

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.

Can't beat the Apple Cinema Display 27 inch (or if you're a PC guy, the Dell UltraSharp 27 inch). Got two of them, love them, would never go back.

Thank you for the suggestions, I'll work on making the site more clear to a technical audience.

Our first draft of the site was actually very heavy on the tech details but we ended up trying to dumb it down a bit to appeal to a wider audience. It's tough trying to find a good balance between the two.

We did indeed use Chromium as a base but have implemented a great deal of extra modifications on top to make this the ideal solution for offscreen embedding. Significant portions of the renderer, plugin containers, and Javascript system had to be re-written.

We're working on a Linux port for use server-side but that's not to say our current framework is not headless. We developed this branch to be completely independent of any windowing systems (and have even coaxed Flash and Silverlight to render correctly in such an environment)-- check out our HelloAwesomium sample in the SDK, it runs straight from the command-line and outputs a JPEG.