Based on my experience with CefGlue, - a .NET/Mono binding to CEF1 - i have some thoughts about CEF C API.
CEF-side it is code located in libcef (dll-side in cef c api docs).
Other-side it is same as in c api, i.e. it is client-side.
In CLR world: cef-side it is same as native-side, and other-side it is same as managed-side.
CEF API works with various types and objects.
Subject to revision for this proposal it is:
1. Primitive value types -- (currently i'm skip this, but for future - in some cases - some little restrictions must be applied).
2. Non-primitive types, which act as primitive value types -- it is a CefString (big question, but currently we also just skip it).
3. Complex value types (structs) -- (also currently skip this).
CEF1 now have two classes of objects with predefined interface/contract (class with virtual methods):
4. Objects that created by CEF-side: for example CefV8Value, CefBrowser and etc...
5. Objects that created by other-side: for example CefLifeSpanHandler.
6. Method invocation.
How it works in CEF1:
For example, we calling method [c]CefV8Context.GetGlobal();[/c] which return to us CefV8Value object.
Internally CEF1 for this do:
0. (real work)
1. creates CefV8ValueImpl object (which implements CefV8Value interface).
2. then create C++ proxy object (which internally object have cef_v8_value_t structure which initialized each time (per proxy object instance)).
3. then returns pointer to cef_v8_value_t structure.
Something like this happens when we needed pass object to CEF-side.
As result, for example, CefClient which returns pointer to cef_display_handler_t - require create proxy from C structure to cpp structure
on each interaction with display handler.
What problems with this methodology:
1. Heavy proxies
CEF creates proxy (i mean c struct) contains pointers to methods, for same methods, for each instance in most cases.
Of course it must fill it with pointers. Most big struct it is cef_v8value_t struct - it is about 150 bytes on x86.
2. Unstable object pointers
CEF always returns new proxies. I.e. CefBrowser.GetMainFrame() - it is one object, but we will got really new proxies after each call.
As result we can't do make equality comparisons.
As result some handlers which have first argument like CefBrowser or CefFrame *REALLY* can't be used one handler for many browsers,
'cause handler can't identify object.
In most cases it is not very big problem, using very little workaround - we can create many handlers and each handler know own browser.
But this is doesn't work with frames or any other objects (i know that frames resolved by names inside, so for frames it is no have sense).
But for browser objects i think that it is have real sense.
Also it is have sense to do not create client-side proxies, if binding require it.
For CefGlue i'm create proxies each time, but alternative way - it is map it to already created object.
3. Each proxy contains pointer to method. It require create dynamic delegates to invoke method via this raw pointers.
I see two problems: invoking via dynamic delegate it is really advanced technique (vs classic calling exported method).
And second it is that in most cases it is pointers to same methods - bindings require cache delegates, to prevent memory blow.
(managed delegates to native code generate special thunk in memory, for example in CLR thunks it is also subject to be GC-ed,
but what happens with others - i'm don't know).
Alternative way (all code it is pseudo code, not C/C++):
1. CefObject (struct)
Declare something like:
- Code: Select all
struct CefObject
{
intptr impl;
intptr vtable;
// note that it can be extended,
// for example to introduce type-id or other useful stuff.
// for example intptr binding_tag, which will be controlled by lang binding, to store associated object handle on other-side
}
2. CefV8Value (interface)
It is very like as cef_v8value_t, it is struct with pointers.
- Code: Select all
struct CefV8ValueVtbl
{
// refcounting stuff
bool IsUndefined(CefV8Value self);
}
3. CEF ABI
All object calls must be available via dll exports, and this methods must call real methods using vtable.
It is just for simplifying.
Most languages already have this kind of invoking methods, and it can be much faster than invoking via delegates.
This is calling thunks must be defined for all methods to all objects. I.e. and for handlers too.
bool CefV8Value_IsUndefined(CefObject<CefV8Value> self)
{
return self->vtable->IsUndefined(self->impl);
}
4. CEF-side CefV8ValueImpl
- Code: Select all
class CefV8ValueImpl
{
private CefObject<CefV8ValueVtbl> obj;
// construction of this class, must properly fill obj struct
// impl field it is will set to 'this'
// and vtable to corresponding vtable (CefV8ValueImpl_vtbl)
static bool IsUndefined(CefV8ValueImpl* self)
{
return self->IsUndefined();
}
bool IsUndefined() { } // no have sense to do it virtual, but it is possible
}
- Code: Select all
const CefV8ValueImpl_vtbl = new CefV8ValueVtbl { CefV8ValueImpl::IsUndefined };
5. Other-side object implementations very similar.
Note that each object can have different vtables, bindings must not assume that it is always one.
It is very like COM, but not a COM.
I very fast write this, may it is not enought, but i hope, it is enought starting point to discussion.