What is CEF?
CEF is an abbreviation for Chromium Embedded Framework, which is an open-source web browser control based on the Google Chromium project, supporting Windows, Linux, and Max platforms. In addition to providing C/C++ interfaces, there are also ports for other languages.
Because it is based on Chromium, CEF supports the HTML5 features implemented in Webkit & Chrome, and is relatively close to Chrome in terms of performance.
CEF also provides the following features: custom plugins, custom protocols, custom Javascrip objects and extensions; Controllable resource loading, navigation, context menus, etc.
Who is using CEF
Let's use some practical examples to illustrate what everyone has done with CEF:
Various browsers
Early dual-core browsers (IE + Webkit), some used CEF as a Webkit kernel browser control.
However, for browsers, extending directly on Chrome is actually the king, and everyone is doing it now (various fast browsers).
Evernote Client (on Windows)
Evernote allows users to paste web pages into notes, and also provides plugins to save web pages as notes.
That must be the need to render the page correctly on the client, and this task is left to CEF.
GitHub Client (on Windows)
GitHub has also packaged libcef.dll, from the performance point of view, the ReadMe page used to display the project must be CEF, and the UI elsewhere may also be partially implemented with pages.
QQ
QQ has implemented some functions and interfaces by embedding IE a long time ago. Since last year, QQ has introduced CEF, replacing some places that used IE before, so that some new features based on Webkit can be used, and at the same time, it has gained advantages in speed, stability, and compatibility.
Adobe Edge Animate & Adobe Edge Reflow
Adobe has launched a complete set of modern web pages (or HTML5?) Edge.
Adobe Edge Animate, for animation, can achieve complex animations by editing the timeline and creating originals (called symbols in Edge Animate).
Edge Reflow is the Design the responsive web. Some people translate it as responsive, which is actually adaptive.
The above two software is basically oriented to the browser of the Webkit kernel, so it is necessary to embed a Webkit kernel to provide a WYSIWYG preview and editing interface. They all used CEF. (The difference between CEF and pure Webkit will be introduced later)
Q+
Under the concept of Web App, Q+ provides a running environment for web pages (simply put: a box of the client and some available APIs), and supports IE and Webkit kernels.
For web development students, the Webkit kernel (actually CEF) we introduced does not need to consider IE's version compatibility issues, which not only improves development efficiency, but also allows us to take advantage of some new HTML5 features. At that time, Q+'s application market, message center, wallpapers, music widgets and other applications were all developed based on the Webkit kernel.
The Q+ project can be said to have made more attempts at CEF, such as:
The developed music widget uses the HTML5 audio tag;
Some applications use the offline functionality of HTML5 (i.e., with a manifest file), but of course there are some twists and turns, and I have gained a lot of experience.
Packaged Webkit Dev Tools.
Custom protocols: For example, access to qplus:// protocols can be redirected to a special folder.
Off Screen Rendering (OSR): By using off-screen rendering + Windows Layered Window, an irregular web page window is created (what is the shape of the opaque area of the web page, what is the shape of the window)
Why embed CEF for clients?
With so many examples, this question is much easier to say:
It is used to display web pages and use various Web services;
Use web pages to do UI;
Use HTML5 features, such as audio, canvas, etc., including CSS3 features.
Off Screen Rendering (OSR):
The so-called OSR is to render the entire page onto a bitmap without creating a real window. Of course, not only rendering, but also a series of APIs to handle mouse, keyboard events, input method events, etc.
This feature is especially useful when real windows cannot be used, such as on Layered Windows, or when rendered to textures in games.
Using OSR features, some interesting effects can be made, such as:
AlloyTeam made Webtop, which uses OSR to make a browser, player, etc.
There is an Awesomium project that also supports OSR, and there are already game projects that use Awesomium to render web pages in games. (Looking at the output file of Awesomium, it should be similar to the implementation of CEF, it is all a package of Chromium, and CEF that Awesomium can do should also be done)
In my spare time, I made a demo and used CEF to render web pages on OpenGL Texture, which can be regarded as a small attempt to apply CEF to the game, as shown in the figure:
in-game browser demo
Why CEF?
IE
IE has been an embedded browser control for a long time, and to be precise, we now have many alternatives to IE.
CEF vs IE：
Compatibility:
IE: The kernel varies from 6 to 10 versions depending on the operating system, and the workload of web development to be compatible with these versions cannot be underestimated.
CEF: It uses the Webkit kernel, and from the characteristics point of view, a CEF version can correspond to a Chrome version number, so that web development has a clear set of features, eliminating the workload of considering compatibility.
HTML5 Standard & New Features:
IE: Of course, older versions of IE do not support the latest HTML features and standards.
CEF: There is no doubt that Webkit and Chrome are at the forefront of supporting new features.
Open Source & Cross-Platform:
IE: Not open source, limited to Windows platform
CEF: Open source, the Webkit and Chromium used are all open source, open source means more customizable possibilities; And it spans Windows, Mac, and Linux.
Off-Screen Rendering (OSR):
IE: You can achieve off-screen rendering through some hacks, but the workload is not small, and it is not officially supported.
CEF: There is a dedicated off-screen rendering mode and corresponding API.
Penetration:
IE: All Windows users have IE, which is the advantage of IE (but some users have incorrect IE settings, which will lead to unusability, such as jscrip{filtering}t.dll not registered, resulting in the inability to use Javascrip{filter}t)
CEF: You have to install and package it yourself
Webkit
Why deliberately compare CEF and Webkit?
I recently read a good article about what Webkit is, what it is not, and why there are so many Webkit ports: "What Developers Need to Know About WebKit"
Here is a rough summary:
Webkit is the parsing and arrangement engine for web pages, which is shared by all Webkit-based browsers. The default Webkit port is Safari, which is the version downloaded from the Webkit source code compilation. There are other Webkit ports, including Chromium, QtWebkit, etc., which have different implementations in 2D graphics, GPU acceleration, Javascrip engine, audio/video decoding, etc.
CEF vs webkit (actually Chromium vs Webkit)
V8 engine, skia's 2D rendering, Chromium's GPU-accelerated implementation, etc., with the help of Chromium's excellent implementation, CEF has also become an excellent Webkit port.
CEF Disadvantages:
Be kind, CEF also has its own shortcomings and limitations, and you can't just mention the advantages, here I will introduce the disadvantages and disadvantages of CEF:
Volume:
The latest version of CEF, the sum of all DLLs should be close to 40M, and it is estimated that it will be 10M+ after compression. If your project itself is not large in size and cannot receive it, then CEF is not for you.
Of course, for games that are now calculated by G, this volume should still be acceptable.
For ordinary client projects, it depends on whether the project itself needs to use the features implemented by CEF, and whether it is worth increasing the installation package of the product so much. Of course, there are also some implementation compromises here, such as downloading after installation (I personally don't think this is meaningful, after all, users who install packages can also choose to download software to speed up)
Cache:
Chrome's cache is designed to only have one process read and write, and the same is true for CEF.
For clients that need to be opened multiple times, only a different cache folder can be specified for each process instance. However, this undoubtedly increases the hard disk usage, and also causes some files that were originally cached to be downloaded multiple times (for example, process A caches jQuery.js, process B has to request and cache once because it caches different directories jQueyr.js
OSR：
OSR is currently not like real window mode, which can be accelerated by GPU, and OSR can only be rendered using software, which means that some CSS 3D effects cannot be supported.
However, the characteristics of OSR are still being improved, and I personally think it is still worth looking forward to.
What to share later
After writing so much, it can be regarded as an introduction to CEF, and I will write some dry goods in the future, that is, how to use CEF, including:
CEF code acquisition, compilation, embedding, processing API calls of pages and clients, OSR off-screen rendering, caching, custom protocols, CEF1 & CEF3, etc.
Well, that's all for today.
|
Posted on 9/22/2017 4:19:26 PM
|
|
|
Posted on 2/25/2019 9:14:24 AM
|
Landlord|
Posted on 8/12/2023 8:08:02 PM
|
