How DCEF3 works and how to get the latest build

[Andrew Pratt]

I thought it was time to give back to the community with some detail of how DCEF3 works in Delphi because although this project is great bringing Chromium to Delphi, there is very little documentation and Chromium works in a very different way to normal Delphi controls or the normal Delphi way of doing things.

To start with, to get the latest version you need to checkout Branch 2062 from here: https://code.google.com/p/dcef3/source/browse/?name=2062. This might not be that obvious.

The latest version doesn't seem to allow   CefSingleProcess := true; to work anymore. This prompted us to review our code and gave us an understanding of what is actually going on.

So to start, DCEF3 for Delphi is a wrapper around a set of Chromium/WebKit files compiled for Win32/Win64 which are found in the BIN folder of your source folder.

Chromium and Chrome should not be confused. Your Delphi app uses the WebKit build deployed with your application (the files in the BIN\Win32 or Bin\Win64 folder should normally be in the same folder as your .exe file unless you specify otherwise. It does not use 'the version of Chrome installed on the PC by the user'.

Secondly, you will see any a number of threads that you need to add this to your DPR file for DCEF3 to work

  CefCache := 'cache';
  CefSingleProcess := false;
  if not CefLoadLibDefault then
    Exit;

What I haven't seen anywhere is 'why' or what this actually does.

Chromium is 'interesting' in the way it sets up the browser process. In order to protect different parts of the page rendering process from crashing other parts, multiple copies of your execution are started to serve the request. As a basic understanding there is a separate process for the javascript engine, rendering engine, etc. You will often end up with at least 5 processes running.

The code above detects if the execution (based on command line parameters) of the current executable is the main launch of your application (i.e. you ran it from Delphi, ran it from the desktop) or whether the command line parameters match those of the internal separate processes chrome creates once your application starts. You can see this behavior by placing a showmessage( cmdline ); at the very first line of your .DPR and setting cefSingleProcess := true after this.

This behavior is problematic to Delphi developers as they often place code in initialization sections of units and finalization sections of units which often have assumptions that the .dpr code will run. These init/final sections still execute with each of the spawned WebKit sub-instances and can cause strange crashing behavior that is very hard to track down or debug. If you do get weird crashes at startup/first load when using DCEF3 in non-single process this is probably where your problem lies.

A way around this is to tell Chromium to use a different executable for the 'sub-processes'. This executable could be built with ceflib/cefvcl included with no forms and a simple DPR containing only the commands above. For example this .exe could be subWebKit.exe and would ship alongside your MainApp.exe.
To make this process work you would add this line after CefSingleProcess := false;
  CefBrowserSubprocessPath := 'subWebKit.exe';

The second thing to note is that when running in non single process mode your 'process messages' and perhaps your javascript callbacks although I haven't tested this yet might not be running in the same application instance, let alone the same thread as your main application. This means you can't access anything - not even your global variables. There is a message callback service available which you need to use to pass data between the two processes. I will write a further topic on this soon if anyone is interested.

This does make tasks that were very simple in TWebBrowser i.e. getting access to the DOM, much more complex, but the design does have advantages as it stops the browser becoming locked up by code that isn't thread safe and prevents one operation blocking the usability of the page. Because of the separate process you need to re-think your design and pass information back and forward with callbacks rather than grabbing something from the DOM and 'storing it until you need it'.

I hope this helps someone get started with this excellent component. You will see much better rendering performance when switching to CefSingleProcess := false;

[Jason]

Huh. I'm using the latest version from the repo and CefSingleProcess := True works fine for me. I'm in Delphi 2007, which could be relevant.

[Andrew Pratt]

Are you sure you are using branch 2062?

[Jean Lopes]

Really nice. The inter-process communications seems to be a good topic for a detailed documentation, as well as this point you made.

[eric grobler]

Hi Andrew,

Your comments and insights are appreciated and much needed :-)

There is a message callback service available which you need to use to pass data between the two processes.

 I will write a further topic on this soon if anyone is interested

Please do!

I use CEF3 in a student classroom software as a single process where I render static html pages to a projector.

I make use of a lot of Javascript and I assumed the CefSingleProcess failure in the latest version was just a bug!

For static web pages I think multi instances are a bit of an overkill, but it seems I might have to go that route.

Your idea of a dedicated sub-Delphi exe sounds interesting.

Regards

Eric

[Jason]

Where is it you're finding 2062? The latest version I'm seeing in the dcef3 repo is CEF 3.1750.1738. Are you trying to use a libcef.dll not distributed by Henri with the code he's written? I've found that to usually fail miserably.

[Andrew Pratt]

Hi Jason, follow the link in my post for 2062. It is a branch off the main code. Not sure who made it off the top of my head.

SingleProcessMode is not really how Chromium is meant to work anyway. I am not sure if branch 2062 just isn't coding properly or whether single process mode just won't work in future.

You will find the browser works a lot faster not using single process mode anyway.

[Jason]

Ah, okay Andrew. Yeah, I don't usually stray from the master branch. Looks like Henri might have been working on 2062 but had to stop back in Oct. Seems likely it is half-baked if he didn't release it into master. I'd definitely stick with the master. Is there something in 2062 you need? The master branch is working quite well for me.

SingleProcessMode is a must-have for debugging, I've found. I even have some code (posted elsewhere in the group) to automatically turn it on when my app runs under the debugger but leave it off when not.

[Jackson Luiz De Marco]

"the files in the BIN\Win32 or Bin\Win64 folder should normally be in the same folder as your .exe file unless you specify otherwise"

I put to work with dlls in exe folder, but as you said there is a way to specify the folder. How can I do that? 

Please answer even if it's a newbie question.