Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
adamjs
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
31.
▲
by
adamjs
6y ago
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.
32.
▲
by
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 v
33.
▲
by
adamjs
8y ago
Bit hard to explain without examples but while traversing the beziers in shader, I test if we are equidistant to two or more beziers and do special handling to merge the two unclamped fields (normally we clamp 't' between [0, 1] w
34.
▲
by
adamjs
8y ago
Looks neat! Glad to help.
35.
▲
by
adamjs
8y ago
I actually moved all of that to the CPU (parallel, SIMD) and am using it in Ultralight [1] to generate high-precision SDFs for font-glyphs and small paths. I'll release the GPU-based implementation when I have more time. If you're
36.
▲
by
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.
37.
▲
by
adamjs
8y ago
Yep! We plan to expose a C API to make bindings easier to generate.
38.
▲
by
adamjs
8y ago
Interesting, it's not too farfetched of an idea since there is a C++ API for accessing the DOM in WebCore and we have the ability to disable JS completely. I've added this to the issue tracker as an idea to explore. [1] [1] - htt
39.
▲
by
adamjs
8y ago
We've reached peak Hacker News.
40.
▲
by
adamjs
8y ago
To minimize latency, Ultralight runs on the main thread, single-process, and outputs to raw virtual GPU command buffers for consumption by the user. I worked in game engines before so I'm familiar first hand with responsiveness as a de
41.
▲
by
adamjs
8y ago
Hi there: 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 sys
42.
▲
by
adamjs
8y ago
Haha, at ease sergeant, thank you! Building WebKit from scratch was, shall I say, an exquisite learning experience. My first change was re-writing part of the CMake scripts to make it more elegant.
43.
▲
by
adamjs
8y ago
There was actual documentation for 0.8 [1] but the source for it was wiped by an erroneous rm -rf and I couldn't update it for 0.9 in time. Full documentation and tutorials will be published soon. With that said, the SDKs include full
44.
▲
by
adamjs
8y ago
We will be pulling upstream WebKit changes from the Safari stable branch into WebCore, so it's not a "hard hard" fork.
45.
▲
by
adamjs
8y ago
Haha, I totally wrote that up but deleted it at the risk of sounding too fastidious.
46.
▲
by
adamjs
8y ago
Haha, you are welcome! I definitely don't hide, come join our Slack channel here: https://chat.ultralig.ht
47.
▲
by
adamjs
8y ago
Yep! In fact we expose JavaScriptCore API directly to users so your native code can call directly into the VM. Check the samples in the SDK.
48.
▲
by
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.
49.
▲
by
adamjs
8y ago
Great idea! Thanks.
50.
▲
by
adamjs
8y ago
Not to dismiss work done by the Electron team but Electron essentially wraps Chromium via CEF, so, tangentially it was made possible by Google.
51.
▲
by
adamjs
8y ago
It's WebKit-based, not Chromium-based. The only LGPL component of WebKit is WebCore and we have open-sourced our WebCore module here: https://github.com/ultralight-ux/ultralight-webcore
52.
▲
by
adamjs
8y ago
The team is currently me :). Will be hiring soon.
53.
▲
by
adamjs
8y ago
The OpenGL driver is almost complete, it shouldn't be too difficult to port to OpenGL ES. We're definitely interested in targeting embedded devices with this.
54.
▲
by
adamjs
8y ago
That's really interesting! Thanks for sharing. 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) fo
55.
▲
by
adamjs
8y ago
That's a great suggestion and I will make a better comparision with real numbers in the next release. Currently, the memory usage is similar or less than that of Chrome/Safari, with most memory being allocated by the JavaScriptCor
56.
▲
by
adamjs
8y ago
It's not a subset, it's the full WebKit layout engine underneath and supports most modern HTML5/CSS/JS. Ultralight can render full websites just fine and is also a full browser runtime, the SDK ships with a Browser sampl
57.
▲
by
adamjs
8y ago
- The beta is definitely not rock-solid stable yet but reasonably runs a majority of major websites. The current branch of Ultralight is based off of a stable branch of Safari/WebKit. - The Ultralight library itself has no dependencie
58.
▲
by
adamjs
8y ago
The WebCore module of Ultralight is open-source: https://github.com/ultralight-ux/ultralight-webcore
59.
▲
by
adamjs
8y ago
Definitely yes on an OpenGL GPUDriver implementation (it's done), Vulkan is still being explored.
60.
▲
by
adamjs
8y ago
This thing HAS existed for a while (CEF/Electron, Awesomium, QtWebKit, GTKWebKit, etc.) but the size, memory usage, and flexibility has always been prohibitive. Ultralight addresses all of those through a new, lightweight WebKit fork g
More ›