Berkelium in Ogre

[hellcatv]

Hi Ogre Forum Folks:

The Sirikata dev team would like to announce the release of Berkelium, a Chromium web browser that can render to a memory buffer, such as a texture.
Shown here is Berkelium running inside Sirikata, our Ogre3d-based virtual world system.
http://www.youtube.com/watch?v=zUdrflSOe_Q .

Our system uses Chromium's multiprocess rendering architecture to maintain process sandboxing and utilize Google's optimized rendering to a memory buffer directly, without modifying their render processes (except for adding a translucency option to their browser panes to save out alpha values). This makes the code a pretty thin wrapper around the google RenderViewHost class to callback the user with a memory buffer and damage rect instead of drawing directly to a gtk or hwnd window. This means flash "just works" on all platforms and that the performance is fantastic.

We've made the Sirikata system easy to compile for windows, mac and linux so you can quickly get a version running and see how it works inside ogre. And the Berkelium interface is also quite small so you can simply grab the windows Berkelium SDK and link your own ogre app against it. We've made sure to stick to simple enough code with a well defined c-like API so that you can link against it in either Debug or Release mode on Visual Studio.

All of our code is BSD licensed, so you can use it inside your commercial or free projects at will.

And now some screenshots of Berkelium inside Sirikata running on Ogre3D








I would love to hear comments and feedback from y'all

[my.name]

Very interestingly =)

[DanielSefton]

Cool.

Your screenshots look a bit dull/dark, add some sun light!

How does this compare to Awesomium? Also uses Chromium.

[jacmoe]

Nothing compares to Awesomium - it's not maintained, the author abandoned us and went commercial.
Still haven't forgiven him for doing that, especially after building up a lot of hype around it, releasing it as open source, and then leaving it for cash.

If this is open source, which it is, and maintained, which it is - then Awesomium can rest in peace.

[Klaim]

Well we don't have any news from Adam so we effectively don't know where Navi/Awesomium is going right now... not sure he's doing something on it.

So, this project is interesting. I'm using Awesomium at the moment but will be soon limited so if your project can solve mine, it's really good. You should take a look at Awesomium, see what features are interesting for it's ursers. (like the communication with javascript features)

[jacmoe]

Well we don't have any news from Adam so we effectively don't know where Navi/Awesomium is going right now... not sure he's doing something on it.

He was very clear in his statement on his site: 'No further development'.

[hellcatv]

Glad you folks are interested!

We're definitely going to maintain it since we depend on it for our mothership project, sirikata, and in fact the reason we started development is due to the discontinuation of Awesomium support and our own development trouble bringing awesomium up to the 19xxx svn version and into the 20000's due to reliance on lots of Webkit internals that kept shifting around and started bringing in much of the multiprocess stuff into the required dependencies. When updating to the 20000's, we'd run Awesomium and the chrome libs would start launching other processes to try to bring up defunct renderers in other processes instead of displaying them locally.

At that point we decided it would be easier to work with chromium instead of against it by utilizing their multiprocess rendering facilities rather than avoiding them. This turned out to make the code much simpler inside. This necessitated we start from scratch, so we decided at that point to make the license more liberal, giving you folks a BSD licensed browser to go with the equally free MIT license coming in the form of Ogre 1.7

I think you'll find that while the internals look quite different, the external interface is very similar to awesomium, with the exception that the callback allows for scrolling events that ask you to shift the image some number of pixels in a given direction and offering a nice strip of replacement pixels.

We've also utilized the javascript interface in a very similar manner with berkelium, but the calling code unfortunately has to look a bit different. We need to go through the externals interface that chrome exposes by default, so we cannot simply dip our C++ objects into V8 land and wrap them. On the other hand, we do provide a number of hooks so you can register for callbacks by name and so you can send javascript commands to the given rendering process.

Let me know if you run into any problems when using our libs

PS: Sorry about the lighting--we just switched from incandescents to CFLs

[Praetor]

Looks really great. For me, at least, the timing is really perfect. Before diving in an looking for myself I only have one question: can we load files into the system from memory, as in inject our own html, css, javascript etc.?

[Klaim]

He was very clear in his statement on his site: 'No further development'.

Really? I can't find this quote anywhere.. can you point me to it?

[Klaim]

hellcatv> Excellent
Will try to replace Navi by your lib in my project to get a taste.

can we load files into the system from memory, as in inject our own html, css, javascript etc.?

I second that question and add : is there a way to limit the calls to specific locations? (see the white/black lists in Awesomium -- I'm not sure they were published in the end...)

[Jusas]

This project is awsum!

I have to ask though, what version of Chromium did you use with Berkelium? I'm asking because I just pulled the latest Chromium sources and compiled them, then tried to compile Berkelium but ran into a big bunch of errors. It seems that some things have changed in Chromium and compiling it with the latest version probably won't work - the interfaces have changed. For example, ViewHostMsg_PaintRect_Params is no longer defined (or has been renamed), digging into older SVN entries shows it being there in previous versions but in the newer ones it has disappeared, I think it's now ViewHostMsg_UpdateRect_Flags (the contents of the structs look the same).

So... if anyone is attempting to compile this with the latest Chromium, better not. You'll be wasting many hours like I did

Would be nice to know which version is the right one to use to be able to compile Berkelium cleanly.

EDIT: To help out finding the differences...
http://src.chromium.org/viewvc/chrome/t ... iew=markup -- Explains some changes...
In addition some classes have been moved to other headers which explains why the compiler complains about undefined types. Shouldn't take too long to fix I hope.

[sinbad]

Great work! Looks really impressive, and the BSD license is obviously going to be popular Fantastic contribution to the community, kudos.

[sinbad]

He was very clear in his statement on his site: 'No further development'.

Really? I can't find this quote anywhere.. can you point me to it?

http://princeofcode.com/blog/?p=267

I don't blame him for his decision here - it's very hard to make a living out of writing open source software and I think he realised that after getting a little too far into Awesomium. I've been through the same realisation process, but for various reasons chose to go in the opposite direction to the one he chose, ie to make Ogre more rather than less open, and basically write off the effort I have to put into Ogre as a 'cost of sale' of other things that I do for a living - and to recognise the positives I get from the community from that. You can't judge him badly for making a different choice, it's his choice to make and not yours - Awesomium 1.0 was LGPL anyway and you could fork it if you wanted.

Of course, Berkelium is now the better option to contribute to rather than an Awesomium 1.0 fork since the BSD license is far more flexible. This is also the reason behind Ogre's MIT license of course

[hellcatv]

We've right now pinned to Chromium version
CHROMIUM_REV=29571
I know it's a bit dated...and we'll rev it soon, but that version is so rock solid that we've been putting energy elsewhere for the last month or so.

On mac and linux it's easy to build Berkelium: you just run
sh util/build-chromium.sh
and it takes care of downloading the needed packages and building chromium
on windows you have to build it manually...or you can just use our SDK which is all prebuilt and you just link to the .lib files there

Also you can inject javascript and even your own files--we do that for the navbar in sirikata (all code is available under BSD there, so you guys can check out sirikata and look at the libproxyobject/plugins/ogre/WebView* files for an example of use inside ogre.

I don't really understand the whitelist thing-- can you give me a use case? I could imagine restricting what people type in the nav bar. I guess it's to lock users into a themed site? I think chromium has some sort of facilities like that---if you guys can figure out how to trigger them we'll pull in your changes to the master berkelium branch (one of the nice things about git is that we don't have to "grant" commit access-- you just use the github.com facilities to fork a branch and we'll get to see commits going on and can pull them in at will--and if we get too lame about pulling them in, then inherently someone else will become community manager)

Let me know if you have further questions

[Klaim]

The idea behind white and black list is to limit requests to specific locations. It's not useful in the case you provide an adress bar in your application, but it's useful in a game for example where you don't want the user to freely go to google or elsewhere but simply run DHTML pages, local or on a specific domain.
To do that, first you need to provide a local adress system (something like file:///) that allow user to specify a folder or a file on the computer, or relative to the applcation, whatever.
Next, a white list that is a list of locations (http or file) that are allowed to be used. Any request to other locations will simply be ignored.
A black list is exactly the reverse of a white list : a list of domain/locations that are not available to the user application.
The user would use one of the two lists. In my game for example I need a white list to allow only gui DHTML files and some game-specific-web-server online access. Any other web page access would be harmful. It also helps to limit some potential piracy harm.

Do you see what I mean?

[hellcatv]

Klaim: I see...I'm not sure we have the cycles to look at whitelists or blacklists right now, but it might not actually be too tricky to add the functionality yourself. If you have a patch to berkelium or make a fork and apply the changes to your fork we'll pull it in the master branch straight away and continue to maintain it.

In response to another question about injection of javascript, here's something we did using the same interface we provide now:
http://sirikata.com/res/speedlimits/Curator.mov
The actual capture was generated with Awesomium at the time but it would be straightforward to recapture it now that we link against Berkelium instead.

As you can see, Berkelium lets you inject events into the world and also receive messages from the world to build the UI up.

[Klaim]

I'll see what I can do once it becomes essential for my project, in few months. The list itself don't seem hard to setup, just have to dig in the requests processes...
By the way, wich compiler was used to generate the SDK?

[Falagard]

Very cool. I've taken a brief look at the Berklium API, looks very similar to Awesomium and Astral (Astral is a wrapper over the Gecko engine done by the author of Awesomium).

I work on software that extensively uses Astral (and hence Gecko) for the user interface and have been looking at moving over to Chromium.

I haven't yet compiled and run Berkelium to determine, so here are a few questions:

1. Does Berkelium support persistent cookies (stored on disk, persisted between sessions)? If not, is that on the roadmap?
2. Does Berkelium support a persistent cache (stored on disk, persisted between sessions)? If not, is that on the roadmap?
3. Do combo / drop down boxes work properly in Berkelium?

Thanks!

Clay

[hellcatv]

We used visual studio 2009...but I think you can probably get away with using it in vc2008, ic++ or vc2009 because it only uses C-like API's to communicate between the systems--I *know* the same .lib works in both release and debug in vc2009 and that only started happening after I simplified the API, and I know the C API is well specified, so as long as the very basic class names are mangled properly it should work across all compilers.

I specify a profile directory
1&2) I believe it does on windows and I think mac... on linux it's a 1 line change to give it a specific home directory--the problem was that if we killed the debugger in linux it would leave around a stale lock file and that would cause us hassle--so that's why we have it generate a new directory on each run in /tmp on linux. Other platforms seem to be more forgiving.
3) I don't believe I've tested on mac or windows, but I know they work on linux when I go to adobe.com and click Contact I get a dropdown with region and language. That required special work to get right. I have a feeling the mac uses some bogus mac-specific calls and that might be a bit trickier. I think windows acts the same as linux so it should work too, but I don't have a windows box handy right now to test.

[Falagard]

Perfect, I'll definitely have a deeper look at Berkelium. Thanks for the reply.

[SwiftCoder]

He was very clear in his statement on his site: 'No further development'.

Really? I can't find this quote anywhere.. can you point me to it?

http://princeofcode.com/blog/?p=267

I am not sure jacmoe's statement quite does justice to the situation. When I queried Adam a month or so back, he indicated that the future commercial versions of Awesomium would be offered under a free license for non-commercial use.

Still, I am glad to see a truly open alternative, not least because I am still waiting for a stable Awesomium build. Any chance of a pre-compiled Berkelium SDK for Mac as well?

[hellcatv]

I'm happy to point the website to a packaged version of Berkelium if someone wants to maintain it, but the mac version of chromium requires itself to be fully integrated with your .app structure (see ppmrender.app when you build berkelium). This makes it difficult to isolate in a separate SDK library. (This restriction is because the chromium parent process expects to find resources in the various portions of the .app structure for when it launches children)

the util/build-chromium.sh script is incredibly straightforward and should check everything out and build it for you without lifting a finger

then just type cmake .; make in the berkelium directory and the libs will fall out, with a sample ppmrender.app binary for you to run to see how things operate
cmake and git are the only dependencies...

If you want to see how to integrate it with another cmake build system you can look at how cmake integrates with berkelium

[ShadeOgre]

simply fantastic, i want to give a try now, but i have some things to do before it

[AshMcConnell]

Excellent!

Looks really good. I don't know the specifics of chromium, but is there a way to separate out the flash support to allow UIs in a similar way to Hikari (a great flash-based UI lib that is only really limited by the fact that it is tied to the flash activeX control)?

All the best,
Ash

[hellcatv]

Ash-
You have two options there...
a) you could use the HTML injection routines to make a webpage that was literally just a single flash object that occupied it in its entirety...then flash could use standard javascript callbacks to get access to your C++ internals.
b) the better option (if possible) is to use the HTML5 canvas tag--that integrates much better into the webpage and is an *open* standard. See some examples here: http://code.google.com/p/cakejs/ (no plugins required)

The other advantage of (b) is that it properly does dirty rectangles---flash just claims the whole page is dirty--which works fine for something like youtube where it really is mostly dirty, but for a large UI it can be rather wasteful of your bandwidth between the CPU and the GPU. So yes.. you can do what you propose by making a simple webpage that simply presents the whole flash object as a UI or you can join us in 2010 (nearly) and use HTML5 Either option is supported by Berkelium