A few Qs, if I may!

[oviano]

I'm looking into this library for possibly using for a game UI, along with some other alternatives like Berkelium and Awesomium and I had a couple of questions.

Does CEF make full use of the work done in Chrome regarding hardware acceleration? I've had a look at some of their designs for the rendering/compositing/GPU pipelines and its complicated!

Also, if I wanted to efficiently combine the output of CEF with my own Direct3D/OpenGL surface how would I best go about it? Would I have to use the CEF off-screen mode, and if so, would this then mean I wasn't able to take advantage of hardware acceleration in the Chrome code anymore?

Any help in clarifying this would be greatly appreciated!

[magreenblatt]

CEF supports hardware acceleration using a single-process architecture that is faster than the Chromium browser for many applications. A single Web page can contain both standard and hardware accelerated content -- the process of combining this content into a single view is called compositing. In off-screen rendering mode the composited view is provided by CEF to the client application as a pixel buffer. The pixel data can then easily be rendered into a graphics context using a texture or image buffer. See the off-screen rendering example in cefclient for sample usage.

CEF is currently being used by a number of game companies including Valve and Desura.

Regards,
Marshall

[oviano]

Thankyou for the reply, Marshall.

In terms of the off screen pixel buffer - in the case of a GPU accelerated composition, does this buffer then reside in video memory? I suppose my concern is that with any of these kind of frameworks that any gains made during composition is negated if the buffer just ends up in system memory at the end of it and then needs copying back to the video card again?

The Google design pages seem to show a distinct pipeline for HA rendering whereby a 'GPU process' is passed the elements of the composition and then draws it directly to the window....how does CEF fit into that?

[cagret]

I can confirm that CEF is faster than Chrome in many ways.
All tests on Athlon XP 1800:
1. Launching my app and displaying main html page takes about 0.3-0.5 sec, launching Chrome and displaying the new tab page takes about 2-3 secs.
2. CEF made recently some enhancements to javascript animations and now they are faster by about 30-40% than in Chrome.
3. I've been doing loading of big html page test which contained 500 images + descriptions, a 1.5 MB html file. CEF displays its content instantly in 0.3 sec (and the rest of the page continues to load, making the total time 5 secs, but to the user the time is really 0.3 sec cause he already sees the page). In Chrome displaying the first content takes about 3 secs (and the rest continues to load making the total time also 5 secs), it's a bad experience compared to CEF to display a white screen to the user for 3 seconds. The total times do not differ, but CEF displays the content instantly so user feel times make it a 10x difference (0.3 sec VS 3 sec).

The only thing that I noticed that is slower in CEF is scrolling of pages, about 2x times slower than in Chrome unfortunately.
Can't say anything about hardware acceleration cause this configuration (Athlon 1800) does not allow it.

[magreenblatt]

Thankyou for the reply, Marshall.

In terms of the off screen pixel buffer - in the case of a GPU accelerated composition, does this buffer then reside in video memory? I suppose my concern is that with any of these kind of frameworks that any gains made during composition is negated if the buffer just ends up in system memory at the end of it and then needs copying back to the video card again?

The Google design pages seem to show a distinct pipeline for HA rendering whereby a 'GPU process' is passed the elements of the composition and then draws it directly to the window....how does CEF fit into that?

Hardware acceleration is only used if the view contains at least one layer with HA content like 3D CSS or WebGL. Chromium and WebKit use Skia (on Windows and Linux) or Core Graphics (on Mac) for rendering of non-HA content, so non-HA content will always involve a bitmap in system memory. It's possible that views containing HA content may render faster in the Chromium browser compared to CEF's off-screen rendering mode. However, any performance advantage is frequently offset by the additional cost of Chromium's multi-process architecture and the need to pass messages via IPC.

Keep in mind that Web pages can be complex and HA rendering times are unlikely to be the limiting performance factor. My experience has been that CEF provides superior performance to the alternatives. Browsers are excellent for UI but I would not use any Web browser as part of a real-time system that requires precise timing or performance characteristics.

[oviano]

It might help if I more clearly describe my requirements, actually.

The idea is that the game UI would be completely driven by HTML+CSS+JS. Ideally we would want to be able to take advantage of all the great work done via the WebKit and Google community in adding various effects (3D CSS transformations is a good example) together with the hardware acceleration that will make them work as smoothly as possible.

The Chrome multi process model is not important, or particularly desirable - the UI would operate from strictly controlled and tested local HTML, so stability shouldn't be an issue and if the single process CEF model brings performance benefits, then great. *By the way, I am assuming here that the CEF single process still runs all the various modules described on the Google pages, like the GPU compositor etc, but just in another thread rather than another process?

Anyway, this would suggest that the obvious way in which to match/exceed the performance of Chrome would be to use an on-screen Window in CEF, rather than an off-screen one.

However! There is one 'action' section of the game where we would want to overlay the UI onto our own Direct3D or OpenGL surface. Now perhaps in the future we'd be able to render our action part using WebGL, but I don't think we're there yet with that technology.

So perhaps it would be possible to look at this in a different way - maybe rather than have CEF render the UI to a system memory buffer and then blend this with our 3D surface I need to be looking at letting CEF do its thing with an on-screen Window, be "the boss" if you like, but somehow be able to insert our own surface into the system as some kind of render layer that the compositor uses as its backdrop?

That way we would get the best of all Worlds.

Of course, I have no idea if it's possible and I'm largely thinking outloud.

-----

*The only doubt I have about this assumption is that I just compiled both the test_shell and Chrome proper from the stable Chrome 12 branch from a week or two ago, and went to this page:

http://www.satine.org/research/webkit/s ... stack.html

The full Chrome build renders this quickly and smoothly, but test_shell initially was unable to apply the 3D transformations at all until I enabled a bunch of flags in the code. However, while this got the transformations to work (the left and right arrow keys should control the angle of the gallery of photos), they were dog slow and gave the impression of operating in software. It's possible there is another setting I have overlooked in test_shell of course as I only started looking at the code recently.

[oviano]

I just downloaded the latest Windows CEF test client and that works nicely with the above demo, so that probably answers one of my queries above.

[magreenblatt]

What you're describing is essentially a browser-based game. You can integrate your custom widget as a windowless NPAPI plugin to take advantage of the accelerated compositing support. Everything that you mention is possible with CEF. You'll have to experiment with it to satisfy yourself of the performance characteristics. Performance should be comparable to a release build of Chromium.

[oviano]

What you're describing is essentially a browser-based game. You can integrate your custom widget as a windowless NPAPI plugin to take advantage of the accelerated compositing support.

Ah yes, it does sound like what you describe. I'll have a mess around and experiment a bit to see what kind of performance such a plugin would produce.

By the way, I primarily use a Mac, Are there any obvious 'gotchas' or things missing with the code on this platform?

Thankyou for your prompt responses, anyway.

[oviano]

I can confirm that CEF is faster than Chrome in many ways.
All tests on Athlon XP 1800:
1. Launching my app and displaying main html page takes about 0.3-0.5 sec, launching Chrome and displaying the new tab page takes about 2-3 secs.
2. CEF made recently some enhancements to javascript animations and now they are faster by about 30-40% than in Chrome.
3. I've been doing loading of big html page test which contained 500 images + descriptions, a 1.5 MB html file. CEF displays its content instantly in 0.3 sec (and the rest of the page continues to load, making the total time 5 secs, but to the user the time is really 0.3 sec cause he already sees the page). In Chrome displaying the first content takes about 3 secs (and the rest continues to load making the total time also 5 secs), it's a bad experience compared to CEF to display a white screen to the user for 3 seconds. The total times do not differ, but CEF displays the content instantly so user feel times make it a 10x difference (0.3 sec VS 3 sec).

The only thing that I noticed that is slower in CEF is scrolling of pages, about 2x times slower than in Chrome unfortunately.
Can't say anything about hardware acceleration cause this configuration (Athlon 1800) does not allow it.

Cheers for the info - that scrolling slowdown is that when you go via the off-screen window or does your app embed a regular window?

I have a fair bit of experience using the Berkelium library and I always found the scrolling was a bit sluggish there too, mainly I think because of the inherent lag in having to copy from the off-screen buffer to our own UI buffering system though, although maybe the multi-process architecture doesn't help either I'm not sure.