CEF2 Development Status

[fddima]

The "reference identity" problem can be solved by adding IsSame() methods to all CEF object types. I'm open to other ways of implementing the C API provided it can still be mostly auto-generated from the C++ API and doesn't make CEF C++ development more difficult. Suggestions?

Something like JavaScriptCore / WebKit2 API's may be.
Currently CEF C API is very like by structure organization, but works very differs in runtime.

1. All *Impl objects can persist pointer to a C wrapper (C struct), and return this C wrapper when it needed.
2. Same happens with reverse way.
After 1 & 2 will be done, we can see, that any objects can be plain C++ object with "native struct" aggregated inside, which will have (as minimum) two pointers on C++ struct (for impl / proxy), and for method table (C) for this object kind. Then other-side world can simple get pointer to this C struct.
Also, is very good to have static methods which can call virtual methods, i.e. much easy to use cef_v8value_get_string_value(v8ValueHandle) which access to real virtual method via object pointer. It is much easiest to creating other bindings for other languages.

But at this moment there is are absolutely doesn't matter, without understanding core functionality (i mean chromium/browser).

PS: WebKit2 API (WebKit's multi-process architechture, it is different from Chromium's) uses "Injection Bundles" to get closer integration with browser. InjectionBundle it is separate module, which loaded in to "renderer" process, and got important messages like didClearWindowObject, etc... I mean all JS bindings are possible now only from bundle, and as i'm understand rightly -> if any IPC required with host process -> it is end-user's zone. As for me - good idea.

[magreenblatt]

Currently CEF C API is very like by structure organization, but works very differs in runtime.

1. All *Impl objects can persist pointer to a C wrapper (C struct), and return this C wrapper when it needed.
2. Same happens with reverse way.
After 1 & 2 will be done, we can see, that any objects can be plain C++ object with "native struct" aggregated inside, which will have (as minimum) two pointers on C++ struct (for impl / proxy), and for method table (C) for this object kind. Then other-side world can simple get pointer to this C struct.
Also, is very good to have static methods which can call virtual methods, i.e. much easy to use cef_v8value_get_string_value(v8ValueHandle) which access to real virtual method via object pointer. It is much easiest to creating other bindings for other languages.

It would be rather easy to use global functions instead of function pointers as you suggest. What would we use as the "handle" object? We could use the impl C++ object pointers cast to some opaque void* type, but that may be too easy to abuse (people wanting to cast to the C++ type instead of using correct reference counting wrappers, string functions, etc). If using global functions instead of function pointers what is the need for a proxy object vs just passing the impl C++ object pointer?

PS: WebKit2 API (WebKit's multi-process architechture, it is different from Chromium's) uses "Injection Bundles" to get closer integration with browser. InjectionBundle it is separate module, which loaded in to "renderer" process, and got important messages like didClearWindowObject, etc... I mean all JS bindings are possible now only from bundle, and as i'm understand rightly -> if any IPC required with host process -> it is end-user's zone. As for me - good idea.

I tried to find information on "Injection Bundles" but all I could locate was the (undocumented) source code:
http://trac.webkit.org/browser/trunk/So ... tedBundle/
Are you aware of any documents that discuss the design/usage of "Injection Bundles"?

[magreenblatt]

It would be rather easy to use global functions instead of function pointers as you suggest. What would we use as the "handle" object? We could use the impl C++ object pointers cast to some opaque void* type, but that may be too easy to abuse (people wanting to cast to the C++ type instead of using correct reference counting wrappers, string functions, etc). If using global functions instead of function pointers what is the need for a proxy object vs just passing the impl C++ object pointer?

Actually, I don't think we can do away with function pointers completely. We'll still need them to make sure that memory allocation and deallocation occurs on the correct side of the DLL boundary. For example, calling release() on a client-implemented object needs to delete that object on the client side. Having the client provide a pointer to the release() implementation is the only way that I can immediately think of to do this.

[fddima]

It would be rather easy to use global functions instead of function pointers as you suggest. What would we use as the "handle" object? We could use the impl C++ object pointers cast to some opaque void* type, but that may be too easy to abuse (people wanting to cast to the C++ type instead of using correct reference counting wrappers, string functions, etc). If using global functions instead of function pointers what is the need for a proxy object vs just passing the impl C++ object pointer?

There is a good question. For example WebKit2 have toImpl/toAPI function templates which do this work. I'm don't know what kind of pointer must be used.
While current CEF API require to allocate handler structures by end-user code -> it is required to pass structure pointer. But this limitation can be simply solved by create proxy-types from structures. I mean, that all object allocations can do CEF. I.e. something like CefRequestHandlerHandle cef_create_request_handler(<<<structure that describe it>>>). Where CefRequestHandlerHandle it is anonymous pointer... i'm really don't know to C++ or C struct - in any case conversions must done by library templates, not by C-cast style.
But, important next: current cef's structures - it is method tables. It is good idea, but look, for example:
In CefGlue i'm fill this structure with individual pointers per-instance of object class (for handlers), and then simply ignore self pointer when i got callback, - in any case it is allow to do not map this self pointer to managed object. When converting are possible only via dictionary/map - this can be about 100x-1000x slower than simple ignoring it . But there is are depended from situation.
But, when i'm calling CEF proxy (from cefglue's perspective), i.e. when i call *Impl object's methods - i need get pointer to function, create delegate to unmanaged pointer and perform call. Of course now, i cache delegate, and do not recreate them per each call - but i'm still need to check, that i get same native pointer.
In situation when we have only one CEF proxy object implementation - it is really bad idea create too large C API object wrapper (like v8value). It doesn't have any sense.
So as for me - better provide static C API methods, which can natively perform C++ virtual calls. Uff.
I think, that passing ponters for handlers and for proxies must use one way. So at this moment i'm really don't know which pointer is better to use.

I tried to find information on "Injection Bundles" but all I could locate was the (undocumented) source code:
http://trac.webkit.org/browser/trunk/So ... tedBundle/
Are you aware of any documents that discuss the design/usage of "Injection Bundles"?

May be some discussions present in mailing list - but i'm not registered, and doesn't know have it search or no.
Information about WebKit2 is very few.
For first:
http://trac.webkit.org/wiki/WebKit2 - general architecture.
http://trac.webkit.org/wiki/April%20201 ... ng/WebKit2 - few strings about (gotten from http://trac.webkit.org/wiki/April%202011%20Meeting ).

And - bests samples (which of course unclean):
http://trac.webkit.org/browser/trunk/To ... TestRunner
http://trac.webkit.org/browser/trunk/Tools/MiniBrowser

[fddima]

After investigating in some methods, WebKit2, cef2 (as way to embedding full-featured chromium browser), now in chromium code base landed new independed layer - Content API (content_shell also exists). In future chromium browser will be built on top of content api. Personally for me - content api - is better choice, 'cause it allow strip unwanted chromium functionality. What is better for CEF and their users - i'm doesn't know - it is completely depends from end-user requirements. Some-times users want to have full-featured browser with all functionality. While i'm interesting only in using chromium as embedded good-featured layouting engine - i'm strongly unlike of current cef2 implementation (too few injections point, and too hard to maintain).
So i'm starting new project (currently only prototype) about wrapping content api. codename is unknown.

[magreenblatt]

Using the content API is definitely one possibility as a basis for the multi-process version of CEF. However, there may be some limitations with using it currently:

1. It's still very much a work in progress.
2. I believe it only supports Windows currently.

This of course just means that anyone using the content API at this point will need to be actively involved in resolving these issues.

[fddima]

Using the content API is definitely one possibility as a basis for the multi-process version of CEF. However, there may be some limitations with using it currently:

1. It's still very much a work in progress.
2. I believe it only supports Windows currently.

This of course just means that anyone using the content API at this point will need to be actively involved in resolving these issues.

Yes, it is true.
It still incomplete even for windows (but afaik it must already work on linux gtk and macosx, i'm don't try, but some initials works in sources are done).

But in any way - all main limitations mainly depends on pending refactoring, mainly by moving and cleaning code from chrome project to content. If i'm understand correctly, content api already used by chrome, but most of *_delegate classes which are must be implemented in content api layer, and can be simply reused (for example showing of context menu / really full-featured devtools agent, not stripped version like in cef1 / etc) - it implemented in chrome project directly. It is really bad. But good that chromium team have official plans to move most of this to content layer, and second - good that we can do own implementations of this (if it really needed), without restrictions, and third - reference implementation already exists in chrome.
Currently content_shell status - it works great for me - it have fast layouting on complex pages (no scrolling problems, etc...), but still no have gpu/accelerated compositing support (or i'm no have way to enable this), absent some feats, like local storage (but session storage looks as exists).

In any case - for me my requirements it is:
1. Staying adaptable and configurable as it possible. Tweaking starting of renderhost / renderer process are required, in generally this is must be controlled by end-user, not by chrome code.
2. Provide good binary (C-like, but C it is not a target) interface, which allow build bindings to other languages around this (even to client-side C++). This is must put many restrictions on public visible types to get good compatibility with different platforms, and require much more helper methods.

While it is require really many hard work which will take a long-time, (most of them, it is create prototype, generate common framework concepts, implementing reusable code generators to build final binary API, and build bindings to other language on top of this API) - so i'm fell free about current incomplete status of Content API.

As, alternative - embedders which are want use only C++, - can use Content API directly, but in this case, they must be ready to be happy with sex around GYP, get base knowledge of common chromium layers, like completely absense of documentation, etc... - i.e. in most cases it is completely unacceptable by complexity. (But give good control around everything).

[sunm42000]

Hi all.
What is the development status now, and where can I download the latest Source Distributions?
thank you;

[magreenblatt]

Hi all.
What is the development status now, and where can I download the latest Source Distributions?
thank you;

Development status information is available here: http://code.google.com/p/chromiumembedd ... ail?id=326

There is nothing available for download at this time.

[anishphilip]

Hi Marshall,

Can you please give us an update on the current status of CEF3 ?