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.htmlThe 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.