Introduction
Browsers are the killer applications that many network device manufacturers need to embed in their products. More and more terminal devices presents their contents by web-based applications, benfits from the technology, users can easily access the applicatons from any computer connected to the internet using a standard browser. This contrasts with traditional desktop applications , which are installed on a local computer. Almost any desktop software can be developed as a web-based application.
Now, The most popular web browsers on embeded devices are Chrome,
Chromium ,Firefox, Safari. We adopt a open source browser named midori which is based on webkitgtk as a demostration for our platform capablities. but, It needs a deep investigation to choose a proper browser to meet diverse application scenario and demands. Here lists several criterial we think about on the project mozart for you.
- Tremendously active community support Behind, with input from community developers, issues can be solved quickly and new features can be developed continuously.
-
Lightweight, A lightweight web browser is a web browser that sacrifices some of the features of a manstream web browser in order to reduce the consumption of system resources, especially to minimize the memory footprint.
- Make full use of hardware resources, that means takes advantages of the GPU to provide hardware accelerations CSS, WebGL, and html5 built-in video tag.
- Full features of W3C HTML5 standard support, supports webrtc,websocket ,web-gl and built-in multimedia components.
- Open-Source, License Business-friendly, So Customers can use freely without payments.
as shown below table:
nd basically, we believe the two browsers, mozilla firefox and chromium can meet our customers requirments.
- WebKitGTK, a browser engine used in Apple`s safari browser and other products. And it is also the ancestors of Blink, which is the defaulty web engine of chromium(chrome). Although there are many browsers developed based on it, there are no active community for the browser issue fix and new feature keeping developments, may be safari is a exception, but it is a proprietary software, and can only be running on MacOS and IOS.
- WpeWebKit, same reason with WebKitGTK, not suitable on the scenario for well-developted browser demands.
- Genko, the web-engine of mozilla-firefox, which is well-know as one of the most popular browsers. And meets our requirments.
- Chrome, chrome is developed by google, google releases the majority of chrome`s source code as the chromium open-source project, however, chrome itself is a proprietary software, so it can`t be used on commerical projects.
- Chromium, chromium is an open-source web-browser project started by google target to provide the source code for the proprietary google chrome browser, the two browsers share the majority of code and features, though there are some minor differences in features and logos, and thy are different licensing. Based on blink engine, chromium only use WebCore, and include its own javascript engine named V8 and multiprocess system. We select is as our 2nd candadite except mozilla in the project.
- CEF, the Chromium Embeded Framework is an open source framework for embeding a web browser engine based on the chromium core, it allows developers to add web-browser control and implement an HTML5-based layout GUI in a desktop application or to provide web browser capabilities to a software application or game. Our candidate.
Basically, the relationship between KHTML, webkit, blink and chromium is like thiat:
Chromium Architecture
This section i present an analysis of the google chromium web browser, The golal of this section was to analyze the availbale documentation on the chromium project and determine a conceptural architecture for the system. From the perspective of function, the chromium can be divided into serval subsystems, such as multi-meida, display, javascript engine, plugins, multi-process, network, Etc. And through the functional comparation, we give the feasibility analysis of porting chromium to project, including the schedule evalution..
This section serves as a summary feasibility evalution of chromium running on project, so there wont be the conrete technology details of the google chromium.
The reference architecture of a web browser maps comfortably to Google Chrome's subsystems, as it contains all the components in the web browser domain that are portrayed in below diagram.
Analysis:
- User Interface, The user interface is the subsystem that user explicity sees, It is the layer that allows the user to access the functionality of the browser in a method that ideally should be understandable and easy to see.
- Browser, In terms of managing the different subsystems, the browser is the most central component of chromium, the browser is responsible for the following list of tasks:
- Spawing new tabs
- Communication with the network
- Handing the user input
- Window management
- Location bar
- Disk Cache
- Cookie DataBase
- History Database
- PasswdDatabase
- Networking, the network stack handles all universal resource locator requests by the browser, fetches the resources from the network, and also requests caches of results for further possible use. It is platform independent and easy to port.
- Javascript interpreter(V8), The javascript interpreter in chromium is V8, it is currently maintained as an open source project.platform independent and easy to port to mozart project.
- Rending Engine(WebKit), WebKit consists of three components , WebCore, JavaScriptCore and WebKit(an API layer around the two formor), however, only the WebCore component is used in chromium. WebCore offers rending engine service to chromium, handing web components such as CSS, DOM, HTML and XHTML.
- XML Parser(libXML & libXSLT), as time progress, XML and its associated technologies are becoming more and more of an integral part of the web browsing experience, chomium use open source code libXML in the browser to handle with the XML. Platform independent, and easy to port.
- Plugins, plugins provide a specific function to the browser that is no already contained therein, for example, the adobe reader plugin allows PDF documents to be viewed insied chromium and the quicktime plugin allows videos to be viewed inside chromium tab.
- DisplayBackEnd, chromium use skia for render, skia is google`s in-house graphic renderer, which provide high performance grahics rending for everting but text. Skia did not involed with lowlevel display implementation, both X11 and wayland can be taken as its backend. Work principle with wayland show below graph.
- Flash player plugin. Adobe Flash player plugin is a lightweight browser plugin and rich internet application runtime for multi-meida process, games and so on. it is wildey used during former days, and would be replaced by html5 in the future. Chromium has built-in flash player plugin called ppapi-flashplayer. In july 2017, adobe announced that it would end support for flash player in 2020. The html5 will candidate.
- Multi-media. Chromium take ffmpeg as its media backend engine. Ffmpeg is a free software project, the product of which is a vast software suit of libraries and programs for handing video, audio, and other multi-media files and streams. But now, mozart platform not support.
Above all, the common functionality is not complete enough because we dont support ffmpeg framework on mozart project. But, it is can be dealt with by use ffmpeg software codec temporily and then enable the hardware acceleration later.
Conclusion
From the analysis of above section, we can lists the items support situation that is platform dependent of mozart porject as below table.
components |
Mozart supports situation |
comment |
network |
yes |
|
Display backend |
Yes(wayland) |
|
Media backend |
No(only gstreamer, noffmpeg) |
Mozart cant suppport ffmpeg |
Flash plugin |
Yes |
Would end support 2020 |
others |
Platform independent or ready on mozart |
|
The main problem is:
- Chromium and CEF perform the video playback function with FFMEG framwork, although its almostly works on all platforms, but software decoding is not a right option on embded linux platforms. The ffmpeg video codec should be replaced by sunxi hardware decoder accelerator, shown as below
- Building Chromium using Yocto, need dealt with compille and dependency staff problems.
- The footprint may bigger than now webkitgtk midori implementation, There are demo implemetations in open source community for firefox and chromium porting to yocto project. We can take this for reference.
结束!