adamjs's comments

They might want to check out what VNC has been doing since 1998– keep the client-pull model, break the framebuffer up into tiles and, when client requests an update, perform a diff against last frame sent, composite the updated tiles client-side. (This is what VNC falls back to when it doesn’t have damage-tracking from the OS compositor)

This would really cut down on the bandwidth of static coding terminals where 90% of screen is just cursor flashing or small bits of text moving.

If they really wanted to be ambitious they could also detect scrolling and do an optimization client-side where it translates some of the existing areas (look up CopyRect command in VNC).

Two use-cases jump to mind:

* Allows incremental porting of large codebases to ARM. (It's not always feasible to port everything at once-- I have a few projects with lots of hand-optimized SSE code, for example.)

* Allows usage of third-party x64 DLLs in ARM apps without recompilation. (Source isn't always available or might be too much of a headache to port on your own.)

We wrote exactly that for our game-focused port of WebKit [1].

CPU renderer uses a tiny, custom fork of Skia (we only use the path rasterizer and their SSE2, AVX2, NEON backends) and our GPU renderer draws directly on GPU via tessellated paths / hardware MSAA (DX11, DX12, GL, Metal, Vulkan).

[1] https://ultralig.ht

Every language has its own merits, there's no single language that's universally the best for every task.

With that said, C++ and Rust both occupy similar domains (high-performance, low-level, often interacts with OS syscalls or hardware).

Pros of C++:

- More mature, excellent library ecosystem, decades of code to reference from.

- Syntax is arguably easier to read and write

- It's very popular (top 6th language on GitHub), lots of talent to hire from.

Pros of Rust:

- Memory safety, it's much harder to introduce bugs of a certain type.

- The borrow checker makes it easier to reason about lifetimes of objects.

- Cargo is great for pulling in libraries (just needs more of them).

For me personally (graphics / game-dev), cost and speed of development is the deciding factor. I use both: C++ by default, and Rust for low-level, safety-critical code.

hey Nate! I still remember-- new website looks amazing!

For sure, feel free to hit me up on Discord if you want to chat.

Ultralight is definitely not abandoned, 1.3-beta will be released end of this week (nightly builds have been available for the past year) and ARM64 support will be available in the 1.4-dev branch later this year.

Feel free to contact me at adam {at} ultralig.ht if you need support or want a refund.

Definitely not a fork of WPE (which is primarily tied to *nix), Ultralight is built on a platform-agnostic fork of WebCore/JavaScriptCore I started back in 2015.

The goal is actually more ambitious than WPE since we run on every platform and in environments where embedders may provide custom platform functionality (such as games).

Hah I could write a whole post on this topic but ultimately after experimenting with many different approaches on real-world hardware, tesselating the paths and using multi-sampling for AA (you can limit the MSAA to a single area via offscreen buffer) was the most reliable performer.

Real-time SDFs on the GPU still have a definite advantage when it comes to performing strokes, fills, glows, pseudo-blurs and other complex effects in a fill shader but older hardware (especially older integrated graphics) had unacceptable performance when evaluating the bezier.

The alternative is to cache the SDF (precompute on CPU or GPU then upload to VRAM) but then you start running into memory bandwidth and texture memory concerns.

I may still bring it back and lock it to certain hardware but I think we are still a generation or two away from using / abusing shaders for vector paths.

I should also mention that I spent the last two years rewriting our CPU renderer which now has pretty amazing performance across a wide range of hardware (no GPU required, can run it on a headless server or other device). I started by forking Skia’s core rasterizer and wrote a parallel dispatch layer on top (CPU core counts keep increasing so we can start treating them like GPUs for certain ops, see Intel ISPC).

WebKit is BSD but has sub-modules with LGPL code (specifically WebCore, JavaScriptCore, and WTF).

Ultralight is not WebKit (we have a totally different API and use our own renderer, compositor, and event-management code) but we do use a fork of WebCore and JavaScriptCore.

Our fork of WebCore is available under LGPL here: https://github.com/ultralight-ux/WebCore

Yes-- Ultralight (the renderer underneath) has two modes: pure-CPU or pure-GPU. The GPU renderer does all drawing on the GPU using tesselated path geometry and pixel shaders.

All painting is actually emitted as virtual GPU draw calls, interface is here: https://github.com/ultralight-ux/Ultralight-API/blob/master/...

Platform-specific implementations (D3D11 / D3D12 / Metal / OpenGL) are provided in the AppCore repo: https://github.com/ultralight-ux/AppCore

Ultralight dev here-- I've been on the dev-tool side of this equation for the past 13 years so I have insight into why people are actually using HTML/JS/CSS over proprietary UI tech on the desktop.

It's several things-- tons of mature web development frameworks and ecosystems (React, Angular, et al), tons of developers with experience creating and maintaining them, and tons of debugging and support resources (Chrome Dev Tools, Stack Overflow, etc.).

Very difficult to compete against a content creation pipeline like that-- hence why I've made it my mission to get modern HTML UI running performantly everywhere without requiring web developers to learn some new language or toolset.

Also, FWIW, Ultralight does allow you to mix both HTML and native UI (the library can paint offscreen) so you can choose where/when to use each in your app.

Yes-- WebCore has an internal Accessibility API that I'm going to expose in 1.4 to be either handled by the embedder (so you can determine the best way to display / navigate that information) or handled by AppCore (we provide stock implementations of most of the platform API there).

Ultralight dev here-- I remember the KDE days too and have released a fair amount of my software free and open-source.

I had indeed contemplated making Ultralight fully LGPL and charging for support but decided that the incentives really didn't align with making a quality product (quite the opposite-- there would be some motivation to make the product difficult to use to increase revenue which is not something I would ever want to do).

The current license (free for most, but a license is needed past a certain revenue threshold) is my best compromise at making the software free and accessible while still making sure I can keep the lights on and ensure the product continues to be developed into the future.

If you have any concerns about licensing you can always hit me up in our Discord.

Ultralight dev here-- most work has gone into porting Ultralight to various platforms (game consoles and ARM64) the past 2 years. The main focus is less to replace Electron and more to get modern HTML/JS/CSS running everywhere.

The desktop layer (AppCore) is indeed missing some support but I have some cycles allotted to finish them in the next dev branch (1.4).

Yes, Texan here, our neighbors had their faucets dripping but lost power/heat for 30+ hours and pipes froze and burst in the ceiling.

Several factors involved—- the pumping stations lost power so water pressure fell to a trickle. Also homes in Texas are not insulated well-enough to withstand the extreme cold and prolonged lack of heating we experienced.

It was somewhat thermodynamics too— their house was a smaller 1-story house, ours was a larger 2-story house and retained heat long enough to weather the freeze before power came back.

It's definitely still a concern! And our community is growing (come check out our Discord [1]).

Our advantages are much more than memory usage-- it's also distributable size, low-level integration, single-process mode (no external renderer processes), GPU rasterization (and integration into custom GPU drivers), and custom modification of the library itself (most of the library is open-source and on GitHub-- it's much more amenable to "hacking" on than Chromium so it's a better fit if you need a custom HTML rendering solution than Electron).

We're still building out our desktop app runtime (AppCore) to match the API of Electron, but the low-level renderer is already finding a solid foothold inside of games (PC, macOS, and consoles) and headless server renderers.

* [1] https://chat.ultralig.ht

Gave more clarification on this in a reply to parent comment.

Hi there, author of UL and Awesomium here.

We didn't abandon anything, we announced to the community that we were stopping development of Awesomium (our previous Chromium fork), are going to build something new (which turned out to be UL, I wrote the rationale elsewhere in this thread), and continued to support our paid customers for years after (all licenses came with a 1 year annual support contract with option to renew, we would be in contract violation if we didn't).

We did stop maintaining the free online support community which I think is where this sentiment came form. Users were upset that there were no new versions of Awesomium and there was a 4 year gap before the first alpha of Ultralight was released which left a number of users rightfully annoyed.

I personally couldn't promise that were _would_ be a successor project since Ultralight was so experimental (the GPU renderer alone took about 4 years to get working on all platforms). That lack of communication and subsequent gap in updates is what led users to believe the project was abandonware (luckily, I'm here to say it isn't and we're still alive!).

FWIW, Ultralight was actually built in tandem using internal feedback from our existing customers. Many of our current users are ex-Awesomium users.

Yep, we maintain an Xbox port and are porting to PS4, PS5, and Switch next.

Yes, the GPU renderer (and CPU renderer) took about 4 years of R&D alone to get to a usable state (we started on GPU rasterization long before WebRender was even around).

FWIW, a large number of our customers need commercial support and have complex integration concerns that go significantly beyond what those offerings provide (just in the past week, we've been doing custom development for several game studios to get our renderer working in their engine on their platforms).

Also we fully intend to stay current with WebKit trunk (we use a fork of their WebCore/JavaScriptCore modules) since a number of our users need to support modern HTML/JS/CSS (latest build supports ES6 modules, WebAssembly, and more).

Yep, We hit a wall when developing Awesomium-- long story short, the vision for Chromium long-term didn't match with our design goals so we announced to the community that we're starting over with something new (which turned out to be a minimal WebKit-port, eg. Ultralight).

From a business standpoint, we were offering paid commercial support for not just Awesomium but all the Chromium-related parts and that surface area had grown to be way too large to be maintainable. For the product to succeed we had to refocus efforts on building a solution we could fully own and met the requirements of our core market-- and that took about 6 years of R&D.