Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] Chromium Browser
Hi Guillermo,

Thanks for the update!
We'll try out the code on Windows and Mac. We can further discuss on how to integrate the feature with SWT after that. Please see the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=405031 for further comments/questions.

The GitHub page for the project mentions that it only works with GTK2 on linux. This is a blocker for Linux support as SWT support for GTK2 has been dropped in 4.9.
What is the plan to the support Linux-GTK3?

Regards,
Lakshmi

On Mon, 8 Oct 2018 at 06:10, Guillermo Zunino <guillez@xxxxxxxxx> wrote:
Hi SWT Team,

I'm writing about the Chromium browser implementation to bring some updates on the development and start thinking the paths toward moving it to SWT project.

The repository https://github.com/maketechnology/chromium.swt contains latest code with most of APIs implemented, still some work required for sync JS apis and gtk3.

Some highlighted changes were done since my first post, based on feedback and to be more aligned with SWT:
  • Native library code is part of the repo folder chromium-library/, with readme and build instructions.
  • Gradle is no longer used.
  • No longer a separate widget, but a subclass of WebBrowser, to be used with a new constant SWT.CHROMIUM. (Although some clases are copied from SWT until it gets merged with minor change on BrowserFactory to allow instantiation)
  • Chromium implementation is a separate jar/fragment to not pollute SWT with third party dependencies.
  • We still use jnr/asm but those are now part of main eclipse repo now.
  • Bundle fragments contains only our shared lib, and not the CEF binaries. To reduce space and allow separate distribution of those. 
  • Fragments size is reduced to ~500KB
  • CEF binaries can be pointed using the same SWT system property mechanism. 
  • CEF binaries are provided as separate feature/fragments so we can decide to make it part or not of SWT. If is not part of SWT, "Make Technology" will provide ready to use binaries. Also app developers or users can take care of making it available by their own means, and pointing Chromium implementation to use those.
  • Native code in rust is reduced to the bare minimum, with dependencies removed and moving as much as possible code to java.
  • Most SWT browser unit tests already passing. 
Besides finishing the implementation, what things do you think should be addressed before starting the contribution process.

Thanks in advance!

On Sun, Nov 12, 2017 at 7:49 PM 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.
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. 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

--

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


--
Regards,
Lakshmi P Shanmugam

Back to the top