[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Chromium Browser
|
so adding 150MB of CEF binaries to ensure that our users will get the
exact behavior we expect from local testing is a huge win.
For us who don't use the Browser control it would be a showstopper to
add 150MB of additional (for us) useless stuff. So at least make this
optional - or even better - a separate library (not part of SWT).
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://www.syntevo.com/blog
On 2017-11-13 23:21, Ned Twigg wrote:
As an app developer, the big problem with Webkit/XULRunner is that it's
impossible to know if our app will run correctly on the user's machine,
because we can't control what browser versions will be present. Our users
basically don't care about disk space - look at the size of any iPhone app
- so adding 150MB of CEF binaries to ensure that our users will get the
exact behavior we expect from local testing is a huge win.
https://trends.google.com/trends/explore?date=today%205-y&q=electron%20js,xulrunner
We don't use SWT browser, because it causes too many bug reports for us.
Shipping a known version of CEF will allow us to use cutting-edge features
- WebGL, WASM, etc. - without testing for broad cross-browser compat.
ᐧ
Ned Twigg
Lead Software Architect, DiffPlug LLC
540-336-8043 (cell)
888-513-6870 (fax)
340 S Lemon Ave #3433, Walnut, CA 91789
On Mon, Nov 13, 2017 at 12:45 PM, Lakshmi P Shanmugam <
lakshmipriya.bms@xxxxxxxxx> wrote:
Hi Guillermo,
Thank you for the detailed write-up!
My question is regarding the integration and distribution.
With the Webkit and XULRunner browser integration, SWT doesn't distribute
the third-party libraries (Webkit/XULRunner libraries). We require the user
to have the required libraries installed on the system and SWT only
provides the integration library which is required to talk to the
third-party libraries.
Can the Chromium integration be made to work in a similar way, where we
require the user to have CEF downloaded/installed on the system and the
SWT-Chromium integration library can work with it?
Thanks & Regards,
Lakshmi P Shanmugam
On 13 November 2017 at 04:19, Guillermo Zunino <guillez@xxxxxxxxx> wrote:
Hi SWT Team!
I'm Guillermo Zunino (from Make Technology, http://wemaketechnology.com)
and project https://github.com/maketechnology/cefswt.
Mikael Barbero talked about the project with some of you during
EclipseCon Europe and asked me to write to the list. As you show
willingness to integrate the work in SWT, I'm writing to start discussing
some of the challenges and to get your feedback, opinions and ideas.
Here is a post on the subject by Mikael https://medium.com/@mikael.bar
bero/chromium-eclipse-swt-integration-c61f416e97d1
and here is more information of the background, design and original plan
(although the idea now is to integrate it to SWT instead of nebula if
possible): https://docs.google.com/document/d/1xpLxquAZd6SGDK7XvYHoj2g_
PBnnBX8SFhgwIJPv7lg/edit?usp=sharing
I describe below an overview and some of the points which I believe are
the biggest challenges.
Please ask if you want to know more about the selected tools and
libraries, or any other technical or non technical question.
*- Design: *
Currently the widget tries to match SWT browser API but (for now) is a
different widget component in its own bundle. The widget talks to a small
integration layer (native lib) using JNR-FFI (instead of JNA/JNI). And this
native layer talks to CEF framework C APIs.
There are 3 bundle fragments which provide the binaries for each platform
(mac64, win64, linux64).
The native lib is written in Rust language the same as a helper
executable required by CEF to spawn subprocess (CEF is multiprocess).
*- Binaries (and sizes):*
- cefrustlib (.so or .dll) ~2MB
Native layer binding to CEF APIs
We should be able to shrink this to less than 1MB after optimizations.
- cefrust_subp (.exe) ~0.5MB
Helper to spawn CEF subprocesses.
- libcef (.so, .dll or .framework) ~120MB
CEF shared lib. No debugging symbols.
- cef resources ~25MB
Non localized resources used by CEF. Some may not be entirely
required (depending on browser usage), or could be delivered as separate
fragments, for example devtools (5MB) and cef_extensions (3,5MB)
- cef locales (15MB)
Localized resources used by CEF
Our native lib and subprocess helper are included in the git repository
(using git lfs). The rust source code for those is in separate git repo (
https://github.com/maketechnology/cefrust/).
The cef binaries are not part of the git repo but downloaded as part of
the build from http://opensource.spotify.com/cefbuilds/index.html.
The resulting built fragments, as compressed .jars with all binaries
mentioned above inside, are about ~62MB for each platform.
- Build time dependencies
- Rust (used to code and build the native lib and helper)
- This is actually not required during the bundle and fragments
build, as the shared libraries are part of the git repo.
- Gradle (to automate the many build steps)
- Tycho (to build the bundle, fragments and p2 repo)
- Jboss Reddeer (or SWT Bot) for testing
- JUnit
- Run time dependencies and licenses:
- SWT
- JNR-FFI (Apache 2.0) (already in Orbit, but an older version, we
are depending on latest)
- ASM (BSD) (already in Orbit, existing version should work)
- CEF (BSD) (bundled in our fragments)
- Native libs (coded in Rust, we use some third party libs from
crates.io to develop it)
- rust std lib (MIT/Apache-2.0)
- libc (MIT/Apache-2.0)
- X11 (CC0-1.0)
- nix (MIT)
- winapi/user32 (MIT)
- cocoa (MIT / Apache-2.0)
- CEF lifecycle
- The first created Chromium browser extracts the binaries to
~/.swtcef (similar to how swt does) and initializes CEF (renderer and gpu
subprocess are started). CEF has a memory footprint of ~20MB per process
plus the web pages.
- A new subprocess is started for each different domain url.
- CEF is shutdown using a java shutdown hook or explicitly by the
client. Can't be shutdown after the last browser is closed, due it doesn't
support reinitialization. This one is tricky, because shutdown is not a SWT
Browser API, and CEF shutdown must be called in the main thread. The java
hook is called too late sometimes. For eclipse rcp, is better to explicitly
call shutdown on app exit hook.
- CEF versioning
- Currently we are targeting a single CEF/Chromium version, 59 and
should be able to update to 60, 61 and 62 without major issues based on our
analysis. And we try to consume pre-built binaries form
http://opensource.spotify.com/cefbuilds/index.html
<http://opensource.spotify.com/cefbuilds/index.html>. We also have a
single p2 repo.
- But I see somewhere in the future that we may be forced to support
multiple CEF versions and build CEF ourself. For example if CEF drops GTK2
support, we may have to provide separate CEF binaries (maybe targeting
different CEF versions also depending on API breakage) compatible with gtk2
and gtk3. Similar could happen when Wayland support lands on Chromium and
CEF.
Things are not so clear for me here as it depends on upstream project
decisions (Chromium and CEF).
- Integration
- I think the best developer experience, would be to provide this as
a new SWT.CEF (or SWT.CHROMIUM) constant and new subclass of
org.eclipse.swt.browser.WebBrowser. The full browser API is planned
to be implemented and tested using the existing SWT browser test suite.
- The small integration libs can be put into
eclipse.platform.swt.binaries.git repo maybe.
- Given the size of CEF binaries probably they should be continue to
be download during build (http://opensource.spotify.com
/cefbuilds/index.html is the "official" release channel of CEF and
they keep all historical versions).
- Distribution
- Distribution wise I envision this as separate .jars from main swt
.jar given the size of the binaries and the third party dependencies. The
java implementation could be part of main swt, and the native binaries as
separate .jars per platform (valid osgi fragments). This should allow for
plain java apps, to include the desired .jar and for osgi apps to include
the specific fragment. The java implementation can check for the existence
of natives an fail fast if couldn't find it.
This way there is no new dependency introduced to SWT and users
wishing to use Chromium should opt-in for it, instead of making everyone
pay the size and third party dependencies cost.
As said the idea here is to trigger discussion and know your opinions to
move forward.
Best regards, and sorry for the large email!
--
Guillermo Zunino
guillez@xxxxxxxxx
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
