UL uses a fork of WebCore/JavaScriptCore (the layout engine and JavaScript engine from WebKit). It is indeed modified (been working on it 7 years) and released open-source on GitHub.
610 karma · joined September 5, 2013
Follow me on X [2]
[1] http://ultralig.ht
[2] http://x.com/adamjsimmons
1. That Section (5) is left intentionally reserved (empty) since the commercial version of the contract provides commercial license grants. This is typical when offering multiple versions of a contract.
2. Contracts are typically governed by laws of a certain government (this is called venue). You can indeed enter into an agreement with another party using a venue in another country. (FWIW I agree the Free License is a bit too unwieldly-- I'm going to switch to an slimmer alternative that's more grokkable)
3. You would use UL for lower-level control over the embedding itself-- the library allows you to override file system loaders, font loading, drawing/rasterization, clipboard integration, and drawing itself (via GPU display lists). You can think of it like a smaller, lighter, cross-platform WebKit that's way more "hackable" and is designed to display HTML in an existing app rather than function as a standalone browser (right now, we're primarily used in games).
4. ARM64 support is on the way, there'll be an Apple Silicon port later this year.
For your other questions:
- [Is it thread safe?] This is in our docs, the API is not currently thread safe but you can run the whole thing on another thread. (an upcoming multi-process RPC layer is being built around the core API, and that will be thread-safe/async)
- [Can it fall back to software?] Latest build of UL can fully render on CPU, so yes.
- [Will it be contentious for GPU?] The overhead is minimal. Views are painted on an as-needed basis to GPU display lists, you can see the full GPUDriver interface here [1].
- [Only the C & C++ bindings are official] Several users of our community maintain open-source bindings for other languages, we will move into supporting them directly as the project grows.
- [Why couldn't a dev team just embed WebKit?] As one who has worked on exactly that for 11 years, it's really not that simple. The API of WebKit itself is not designed for embedding inside an existing application, and also much of the design decisions of the engine itself is designed to build a browser, not render HTML. Furthermore, most WebKit ports are tied to a specific windowing-system which is a big deal breaker if you're embedding HTML inside exotic, cross-platform environments likes games and headless server apps.
- [What about CPU cycles? GPU cycles? Latency?] Sure I can put up more benchmarks to that effect, the website is undergoing a refresh for the 1.2-stable release so it's out of date.
- [What about Unreal, Unity, Godot?] Several users have already used the API to integrate into Unreal and Unity, we will make an official plugin for all three later.
Hope this helps clear things up! I'm usually available in Discord [2] if you have more questions.
* [1] <https://github.com/ultralight-ux/Ultralight-API/blob/master/...
* [2] <https://chat.ultralig.ht>
If you're interested in the details of the GPU-based implementation, I pre-sort the path data into bins on CPU, encode it to a dynamic texture, traverse the structure in shader using a modified BVH, and calculate the exact distance to individual Beziers using root finding, which I open-sourced here [2]. It's very fast and avoids overdraw through the use of a low-res stencil mask also encoded into texture. There's of course a lot more nuance than that (fill calculation, level-of-detail, etc.) but that's for a long blog post.
- [1] https://ultralig.ht
Pros (Ultralight is...)
- Smaller distributable (25% the size of Electron/CEF or smaller).
- Simpler and easier to build (fewer dependencies and smaller codebase).
- More configurable (users can do custom handling of file system, fonts, GPU rendering, clipboard, and more).
- Potentially more performant (all rendering is done via GPU command buffers).
- First-class support from an actual company.
Cons:
- No support for MathML, Geolocation, WebGL, IndexedDB, WebAudio/Video (for now)
- Less mature and unstable.
- Slower release cycle (might be a pro).
Linux support is planned and will ship when it's ready, you can track its progress here: [1]
Yes, we have plans to publish a C API interface to simplify bindings for other languages.
The WebCore source is available here [2]. The rest of the source is kept closed for now to keep our licensing/support options open. There's a chance we will find a better funding model and will open-source the entire repo in the future.
Yes, I agree the SDK packages should belong on GitHub, and will also be BSD'ing the framework/sample code so users can fork and hack on it at will.
With that said, the SDKs include full samples and framework code and all the API headers are documented so you can get up to speed fast.
- [1] https://ultralig.ht/docs
Trust me, no one is more familiar with the issues of Awesomium (cumbersome licensing, slow update schedule, bloat, etc.) than myself and it was this reason that I decided to start over from the beginning.
Awesomium was similar in scope to CEF (and actually predates it by many months), it's goal was to wrap Chromium and make it accessible via a pixel buffer instead of a platform window.
Chromium in its initial stages was very tight and focused in its scope and only supported a subset of the current web platform we see today, I think the first Awesomium DLLs were something like 18MB or less.
Over the years Chromium grew larger and accumulated more complexity to a point where it was no longer a web renderer but something closer to an OS platform. Many of the features added were somewhat irrelevant for users looking to render HTML as a frontend but downstream developers like Awesomium and CEF had no choice but to integrate their updates as a whole since we were de-facto wrappers.
Ultralight is different. It's a hard fork of WebKit and has a considerable number of differences tuned specifically for embedders (such as the Platform API and virtual GPUDriver). We have much more control over the project and will continue making design decisions that benefit embedding as a first-class use-case.
Reasons to use Ultralight over EAWebKit are ease of use, pure GPU rendering and performance (EAWebKit, last I checked, depends on Cairo for all its rendering), and the backing of an actual commercial company that will support and maintain the product for years to come.
There's actually been several HTML UI projects that "break compatibility with the web" in varying degrees, with some breaking almost completely (eg, Sciter and libRocket) for the sake of simplicity and performance.
The goal of Ultralight was to see if we could strike a balance between modern HTML5 compatibility (eg, actually being able to render the Alexa Top 50) and reducing size and complexity for use in an embedded use-case.
I think we've struck a good balance so far but can go much farther. We plan to support much more of the web platform while still remaining small by use of shared modules (eg, for WebAudio/Video) so users can pick and choose how big of a distributable they want based on feature support.
As an aside, I took 2 years off just to explore if this was possible, partly funded by my previous work on Awesomium. This project is the result of that research and development.
Currently, the memory usage is similar or less than that of Chrome/Safari, with most memory being allocated by the JavaScriptCore VM, render geometry pools, and some by the GPU texture atlas.
So far, we've managed to reduce the total binary size to about 25% of a similar Electron-based app by reducing dependencies to the bare minimum and punting platform features to be handled by the embedder instead. See our Platform API [1].
As far as runtime memory usage goes, a lot of that memory is being allocated by pools and cache structures to improve performance (the same is true in most browsers). We will be implementing a memory management API soon so that this behavior can be configured (offering users the ability to strike a balance between memory usage and performance).
Additionally, Ultralight is NOT multi-process. The overhead of tens to nearly a hundred renderer processes makes sense for sandboxing in a browser situation but not for HTML UI where the assets are controlled by the user and security is less of a concern.
- [1] https://github.com/ultralight-ux/ultralight-0.9-api/tree/mas...
Ultralight can render full websites just fine and is also a full browser runtime, the SDK ships with a Browser sample on macOS and Windows.
With that said, Ultralight is indeed somewhere between libRocket and Electron in terms of size and support. We won't support things that are unrelated to HTML UI (for example WebGL) and are able to reduce our dependencies/size/complexity by limiting said support.
- The Ultralight library itself has no dependencies on D3D11 or Metal. The renderer emits virtual GPU driver commands that are consumed by the user (see GPUDriver.h). We ship a few stock implementations of GPUDriver for major platforms but users can undoubtedly write their own.
Ultralight addresses all of those through a new, lightweight WebKit fork geared specifically for embedding in other apps. This is a major rewrite and has taken 4+ years to complete. I am the former creator of Awesomium and decided to tackle this issue myself.
Also, the library does come with a DOM implementation and most existing JS libraries work just fine.