Hi
author here
> Why yet another project?
Well this is my motivation:
1) A full two-way (library calls and client callbacks) RPC bridge between the render process and the browser process, so I could get access to the V8 engine and the DOM, both of which live in the render process, from within the browser process.
2) An event-driven model for CEF client callbacks instead of handler base classes and/or interfaces, so I could easily access a single callback (or a subset of callbacks) without subscribing to all the callbacks in that handler. Unused callbacks in each handler don't have to do native/managed transitions, they are not even subscribed at the CEF layer.
3) A fast pinvoke layer dealing exclusively with blittable types and pointers. CEF types are not opaque, so this involved the creation of a native layer to wrap the CEF types into opaque types. The two other options are basically using c++/cli, which implies dependencies on VC runtime libraries, or redefine the CEF types as managed types, which implies a lot of copying at the pinvoke layer. The native layer is a statically linked dll without dependencies on VC runtime dlls - if libcef.dll works, then libcfx.dll works as well.
4) A generator for the wrapper types that allows me to switch between CEF versions by replacing one set of CEF C headers by another set of CEF C headers and pressing a button.
Caveats:
#4 isn't perfect yet, sometimes there is a change in the CEF C API that needs to be addressed with an update of the generator.
No cross-platform support - it's windows only. Some work has been done to support linux, and a working prototype exists, but it's just a proof of concept lacking many features (most notably the RPC layer is not working and so isn't the webbrowser control). Currently I don't have time to work on cross-platform support so it's not going to be ready anytime soon, I guess.
> Would it make sense to ask "which project is the best"?
Well, I only know which project is best for me