3 ms·

Hi I'm Andrew McWatters, I author lcef, LuaJIT FFI bindings for Chromium Embedded Framework at https://github.com/Planimeter/lcef https://github.com/Planimeter/

Hi I'm Andrew McWatters, I author lcef, LuaJIT FFI bindings for Chromium Embedded Framework at https://github.com/Planimeter/lcef https://github.com/Planimeter/lcef. I also work on Planimeter's Grid Engine, the largest 2D Lua game engine on GitHub. So, I'm fully invested in both exposing libraries to languages like Lua, and directly integrating those offerings with software. So, while people are in here talking about Electron, which is most likely not your target audience and might be confused as a result, I am your target audience. I am looking for ways to move away from my engine's imperative UI system and to migrate to web-based UIs in an OpenGL setting, and I have been for years. Adam, this looks great, and I've been waiting to see new solutions like this in the game development space for quite some time now. However, the only truly viable solution at the moment in my opinion is still CEF. The proprietary aspect is significant, and while some using Unity and Unreal might be interested based on existing license restrictions, for these reasons, I am not. Can you explain how Ultralight is fundamentally different than projects like Awesomium and libRocket? It seems very similar to your previous work and not enough of a differentiator for someone like myself. Could you tell me why I wouldn't use EAWebKit instead of this? I spent years as a Source Engine developer and avoided both projects because of their proprietary nature, and because of lack of updates to their underlying web browser libraries. I fear this is a repeat of Awesomium, with a similar proprietary nature, and operating in a space where we will not see frequent updates to the underlying web libraries, regardless of using a subset of web technologies that UI developers would care about.

adamjs 8y ago
Hi Andrew, thanks for the comment! 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.
- andrewmcwatters 8y ago
  Sorry this took me all day to get back to you, but thank you for the response! The work you're doing is excellent, and it's fascinating to see the evolution of it. I appreciate the informative breakdown. It gives me a much better understanding of the value proposition. You have a particularly unique understanding of the challenges embedders have and it's great that we have another option in the industry. Thanks for your time!
- rjvs 8y ago
  Does Ultralight provide a pixel buffer or just on-screen rendering?
  - adamjs 8y ago
    Ultralight renders to a virtual GPU command buffer for later consumption by a user-space GPUDriver. We ship implementations of GPUDriver for D3D11 and Metal.
fit2rule 8y ago
I'm of similar ilk (MOAI) to you, but at far lesser magnitude of relevance .. I wanna just say that I'll probably spend a few days next week putting Ultralig.ht into the MOAI engine where I can, and take it for a drive .. To me this represents the best of both worlds, Lua finally driving the HTML ship. Gonna be an interesting year for us Lua frameworks with this thing around. One of the principle 'reasons' for not using Lua for everything, is poor HTML support - welp, "lua_remove(that) -- and all the things..."

adamjs 8y ago

Hi Andrew, thanks for the comment! 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.

andrewmcwatters 8y ago
Sorry this took me all day to get back to you, but thank you for the response! The work you're doing is excellent, and it's fascinating to see the evolution of it. I appreciate the informative breakdown. It gives me a much better understanding of the value proposition. You have a particularly unique understanding of the challenges embedders have and it's great that we have another option in the industry. Thanks for your time!
rjvs 8y ago
Does Ultralight provide a pixel buffer or just on-screen rendering?
- adamjs 8y ago
  Ultralight renders to a virtual GPU command buffer for later consumption by a user-space GPUDriver. We ship implementations of GPUDriver for D3D11 and Metal.

fit2rule 8y ago

I'm of similar ilk (MOAI) to you, but at far lesser magnitude of relevance .. I wanna just say that I'll probably spend a few days next week putting Ultralig.ht into the MOAI engine where I can, and take it for a drive .. To me this represents the best of both worlds, Lua finally driving the HTML ship. Gonna be an interesting year for us Lua frameworks with this thing around. One of the principle 'reasons' for not using Lua for everything, is poor HTML support - welp, "lua_remove(that) -- and all the things..."