6 ms·

A few things strike me immediately here: 1. Whole sections of the license are missing, such as section 5 - it's just not possible to agree to something in this

A few things strike me immediately here: 1. Whole sections of the license are missing, such as section 5 - it's just not possible to agree to something in this state. 2. It's governed by the laws of Texas, so internationally that's not going to work - I'd have to hire a lawyer just to figure out what this means 3. Most importantly, I've no idea why I'd want to use this over embedding Chrome or Servo. 4. There's no ARM support. So no use on RPi, and potentially no use on Mac OS on Apple Silicon, depending on the secret sauce used. That's before I even start to dig deeper - is it thread safe? Can it fall back to software renderer if needed? Will it be contentious for the GPU with other code that wants to use it? Only the C & C++ bindings are official, the others are 'community maintained'. Whatever that means. What I don't get, is why couldn't a dev team just embed WebKit directly - what does this really give? Can it put a browser in game in 3D, or is it a 2D overlay? Will it work with VR / AR? The website makes a big deal over memory usage, which might be important in some cases, but what about CPU cycles? GPU cycles? Latency? Impact on framerate? Compatibility with Unreal, Unity, Godot, other engines? I think it's a good project, but there's a lot of considerations before I'd even download for experiments.

KenanSulayman 6y ago
1. Valid point. 2. ? 3. Chrome (or more specifically CEF -- Chromium Embedded Framework, the one used by Spotify et al.) is significantly more heavy than UL. Memory use is massive. Google doesn't care about API stability and ABI breakage is so common you'll have to keep up with all API changes (the ones published and documented anyway...) to get anything done. Good luck embedding Servo! 4. ARM support is coming. --- > the others are 'community maintained'. Whatever that means. I maintain the Rust binding to Ultralight [0] via the CAPI to provide an ergonomic way for people to work with it. Adam is busy improving Ultralight itself, so I find it worthwhile to maintain it. That's what it means. [0] https://github.com/psychonautwiki/rust-ul https://github.com/psychonautwiki/rust-ul
- OskarS 6y ago
  > Good luck embedding Servo! You know, it doesn't really seem that hard to embed Servo in a Rust application [0]. It's a pretty interesting read. Anyone know how stable Servo is for this kind of thing? It's not uninteresting as a cross-platform GUI solution or as more lightweight alternative to CEF (assuming it is more lightweight, I haven't done the science on it or anything). Given that you have total control over everything it renders, it's not massively important if it's not 100% HTML compliant or whatever. Interesting space to watch for the future. Hopefully the Mozilla layoffs don't doom Servo. [0]: https://github.com/paulrouget/servo-embedding-example https://github.com/paulrouget/servo-embedding-example
  - KenanSulayman 6y ago
    That's a great repository, thanks. However, Servo just isn't ready yet. There are just so many rendering issues that it's worth waiting for it to become more mature. (If you don't believe me, open https://psychonautwiki.org https://psychonautwiki.org with Servo..)
- rozab 6y ago
  Ok, ok, hold the phone. Why does the psychonaut wiki maintain the rust bindings?
  - KenanSulayman 6y ago
    I'm using headless UL to statically render articles on-demand so that CDN caches can be warmed up at each PoP so that people from less fortunate areas (middle-africa, southern americas, researchers in either pole of the earth -- yes we had them, former soviet countries, ..) can access the wiki just like any other user would. It strips out the unneccessary bells and whistles. Also I think Adam is a great person and I think it's worthwhile to support his project.
    - adamjs 6y ago
      Thank you!
ensiferum 6y ago
"What I don't get, is why couldn't a dev team just embed WebKit directly - what does this really give? Can it put a browser in game in 3D, or is it a 2D overlay? Will it work with VR / AR?" It really is not that simple. Rendering a modern webpage or webapp requires a lot of components. You can't just take webkit and call it a day. For example in the chromium engine Blink which is the Webkit fork doesn't event render pages. It consumes HTML and CSS and produces "display lists" i.e lists of drawing commands. Those are fed to a rasterizer engine that must maintain a whole stack of trandormable layers which are managed in various render trees. Finally pages are radterized in tiles and then composited together for the final image that is show in the viewport. All of this covers millions of lines of code on top of Blink! And we're not even talking about things such as executing JS or syncing JS input handlers with the rendering or doing the actual page loads over HTTP/S or handling windowing and platform APIs and user input etc. All of which are really more or less essential in order to make anything that is actually useful.
- jakearmitage 6y ago
  Uh... yes you can: Glib::RefPtr<Gtk::Application> app = Gtk::Application::create(""); Gtk::Window window; window.set_default_size(1366, 768); WebKitWebContext* context = webkit_web_context_new_ephemeral(); WebKitCookieManager* cookies = webkit_web_context_get_cookie_manager(context); WebKitWebView* widget = WEBKIT_WEB_VIEW(webkit_web_view_new_with_context(context)); Gtk::Widget* wrapper = Glib::wrap(GTK_WIDGET(widget)); WebKitSettings* settings = webkit_web_view_get_settings(widget); Gtk::Box layout(Gtk::ORIENTATION_VERTICAL); window.add(layout); webkit_web_view_load_uri(widget, parse_address(argv[1]).c_str()); window.show_all(); app->run(window); exit(0); Done.
  - adamjs 6y ago
    FWIW Ultralight isn't tied to GTK or any windowing system (API is platform-agnostic), also the core Renderer API doesn't even require a run loop (this is vitally important if you're integrating HTML UI into complex environments like games and headless apps).
MaxBarraclough 6y ago
Good spot regarding the non-Free licence. Instant deal-breaker. It forbids distribution of the source-code, forbids reverse-engineering, and forbids commercial use.
- adamjs 6y ago
  90% of our code is open-source under LGPL and available on GitHub [1], [2]. The distribution as a whole (and core renderer) is under a proprietary, non-free license with provisions for usage in free software. Also the license does not forbid commercial use, the free license allows use in commercial software by companies up to $100K in gross revenue. For use in commercial projects beyond that, we have pricing available on our website [3]. * [1] https://github.com/ultralight-ux/WebCore https://github.com/ultralight-ux/WebCore * [2] https://github.com/ultralight-ux/AppCore https://github.com/ultralight-ux/AppCore * [3] https://ultralig.ht https://ultralig.ht
  - MaxBarraclough 6y ago
    It's still GPL-incompatible, so it's still an instant deal-breaker for me.
adamjs 6y ago
Hi there, lead dev of UL here (seems HN found our beta :)): 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/Ultralight/platform/GPUDriver.h> https://github.com/ultralight-ux/Ultralight-API/blob/master/... * [2] <https://chat.ultralig.ht> https://chat.ultralig.ht>

KenanSulayman 6y ago

1. Valid point. 2. ? 3. Chrome (or more specifically CEF -- Chromium Embedded Framework, the one used by Spotify et al.) is significantly more heavy than UL. Memory use is massive. Google doesn't care about API stability and ABI breakage is so common you'll have to keep up with all API changes (the ones published and documented anyway...) to get anything done. Good luck embedding Servo! 4. ARM support is coming. --- > the others are 'community maintained'. Whatever that means. I maintain the Rust binding to Ultralight [0] via the CAPI to provide an ergonomic way for people to work with it. Adam is busy improving Ultralight itself, so I find it worthwhile to maintain it. That's what it means. [0] https://github.com/psychonautwiki/rust-ul https://github.com/psychonautwiki/rust-ul

OskarS 6y ago
> Good luck embedding Servo! You know, it doesn't really seem that hard to embed Servo in a Rust application [0]. It's a pretty interesting read. Anyone know how stable Servo is for this kind of thing? It's not uninteresting as a cross-platform GUI solution or as more lightweight alternative to CEF (assuming it is more lightweight, I haven't done the science on it or anything). Given that you have total control over everything it renders, it's not massively important if it's not 100% HTML compliant or whatever. Interesting space to watch for the future. Hopefully the Mozilla layoffs don't doom Servo. [0]: https://github.com/paulrouget/servo-embedding-example https://github.com/paulrouget/servo-embedding-example
- KenanSulayman 6y ago
  That's a great repository, thanks. However, Servo just isn't ready yet. There are just so many rendering issues that it's worth waiting for it to become more mature. (If you don't believe me, open https://psychonautwiki.org https://psychonautwiki.org with Servo..)
rozab 6y ago
Ok, ok, hold the phone. Why does the psychonaut wiki maintain the rust bindings?
- KenanSulayman 6y ago
  I'm using headless UL to statically render articles on-demand so that CDN caches can be warmed up at each PoP so that people from less fortunate areas (middle-africa, southern americas, researchers in either pole of the earth -- yes we had them, former soviet countries, ..) can access the wiki just like any other user would. It strips out the unneccessary bells and whistles. Also I think Adam is a great person and I think it's worthwhile to support his project.
  - adamjs 6y ago
    Thank you!

ensiferum 6y ago

"What I don't get, is why couldn't a dev team just embed WebKit directly - what does this really give? Can it put a browser in game in 3D, or is it a 2D overlay? Will it work with VR / AR?" It really is not that simple. Rendering a modern webpage or webapp requires a lot of components. You can't just take webkit and call it a day. For example in the chromium engine Blink which is the Webkit fork doesn't event render pages. It consumes HTML and CSS and produces "display lists" i.e lists of drawing commands. Those are fed to a rasterizer engine that must maintain a whole stack of trandormable layers which are managed in various render trees. Finally pages are radterized in tiles and then composited together for the final image that is show in the viewport. All of this covers millions of lines of code on top of Blink! And we're not even talking about things such as executing JS or syncing JS input handlers with the rendering or doing the actual page loads over HTTP/S or handling windowing and platform APIs and user input etc. All of which are really more or less essential in order to make anything that is actually useful.

jakearmitage 6y ago
Uh... yes you can: Glib::RefPtr<Gtk::Application> app = Gtk::Application::create(""); Gtk::Window window; window.set_default_size(1366, 768); WebKitWebContext* context = webkit_web_context_new_ephemeral(); WebKitCookieManager* cookies = webkit_web_context_get_cookie_manager(context); WebKitWebView* widget = WEBKIT_WEB_VIEW(webkit_web_view_new_with_context(context)); Gtk::Widget* wrapper = Glib::wrap(GTK_WIDGET(widget)); WebKitSettings* settings = webkit_web_view_get_settings(widget); Gtk::Box layout(Gtk::ORIENTATION_VERTICAL); window.add(layout); webkit_web_view_load_uri(widget, parse_address(argv[1]).c_str()); window.show_all(); app->run(window); exit(0); Done.
- adamjs 6y ago
  FWIW Ultralight isn't tied to GTK or any windowing system (API is platform-agnostic), also the core Renderer API doesn't even require a run loop (this is vitally important if you're integrating HTML UI into complex environments like games and headless apps).

MaxBarraclough 6y ago

Good spot regarding the non-Free licence. Instant deal-breaker. It forbids distribution of the source-code, forbids reverse-engineering, and forbids commercial use.

adamjs 6y ago
90% of our code is open-source under LGPL and available on GitHub [1], [2]. The distribution as a whole (and core renderer) is under a proprietary, non-free license with provisions for usage in free software. Also the license does not forbid commercial use, the free license allows use in commercial software by companies up to $100K in gross revenue. For use in commercial projects beyond that, we have pricing available on our website [3]. * [1] https://github.com/ultralight-ux/WebCore https://github.com/ultralight-ux/WebCore * [2] https://github.com/ultralight-ux/AppCore https://github.com/ultralight-ux/AppCore * [3] https://ultralig.ht https://ultralig.ht
- MaxBarraclough 6y ago
  It's still GPL-incompatible, so it's still an instant deal-breaker for me.

adamjs 6y ago

Hi there, lead dev of UL here (seems HN found our beta :)): 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/Ultralight/platform/GPUDriver.h> https://github.com/ultralight-ux/Ultralight-API/blob/master/... * [2] <https://chat.ultralig.ht> https://chat.ultralig.ht>