4 ms·

This looks like a useful framework. To the creator: Could you help me understand how lightweight this is, in terms of memory usage? For instance, how much memo

This looks like a useful framework. To the creator: Could you help me understand how lightweight this is, in terms of memory usage? For instance, how much memory is used to render the Wikipedia sample page, when using Ultralight, vs. using a single Chrome browser tab to do the same? Thanks!

lossolo 8y ago
I second this. Some real world comparisons would be indeed great, to see how much lighter it really is. I would also add some heavy page to compare in context of CPU and memory usage between chromium and this framework.
samstave 8y ago
Where can I find the canonical list of how efficiently each tool renders that wiki page, I'd really like to see it?
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 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/master/include/Ultralight/platform https://github.com/ultralight-ux/ultralight-0.9-api/tree/mas...
- sesteel 8y ago
  Out of curiosity, who is "we"? How big is your team?
  - adamjs 8y ago
    The team is currently me :). Will be hiring soon.
- c-smile 8y ago
  > … HTML UI where the assets are controlled … Real life HTML UI requires a bit more than standard HTML/CSS. At some point you will discover that you will need something like this: elem.popup(popupElem, at) to show arbitrary DOM elements as popup elements (DOM-element-in-its-own-window) like here https://terrainformatica.com/w3/sciter-tooltip.png https://terrainformatica.com/w3/sciter-tooltip.png Yet pure HTML desktop windows: https://sciter.com/html-window/ https://sciter.com/html-window/ with support of Acrylic/Vibrancy: https://sciter.com/sciter-4-2-support-of-acrylic-theming/ https://sciter.com/sciter-4-2-support-of-acrylic-theming/ And at some point you may discover that by adding this to CSS: div.widget { prototype: MyWidget url(/js/widgets.js); } and extending DOM Element by simple elem.merge(newHtml[, callback]) you will have the whole ReactJs thing obsolete/not-needed. All that ... If you want you can contact me so we can discuss all these in details.
- derefr 8y ago
  > with most memory being allocated by the JavaScriptCore VM If I'm writing a green-field HTML5 app, and I don't derive any benefit from Javascript, is the interface between Ultralight and JavaScriptCore clean enough to just rip out the JS support altogether, replacing it with something simpler? I'm picturing: 1. I embed Ultralight into a process that exposes a simple script-loading API, ala the one in JSCore; 2. I write HTML with no <script> elements, just elements with onclick/ontouch/etc. handler attrs, where these handlers just contain a UUID; 3. Ultralight passes the "script code" (i.e. the UUID) to my trivial script-loading API, which simply looks up a native handler based on the provided UUID, and returns its function pointer; 4. Ultralight holds onto that function pointer and treats it just like a regular thunkable Javascript handler function pointer. In other words, all the "dynamism" of the HTML would be handled by native, static code in my compiled binary, with the only thing being set up at runtime being the binding of DOM elements to those known-at-compile-time native handlers. The QML/XAML/NIB approach.
c-smile 8y ago
Just in case, here is Sciter rendering HTML 3.2 specification document using Direct2D/DirectX backend on 3840x2160 screen: https://sciter.com/sciter-fps/ https://sciter.com/sciter-fps/ Real FPS is shown in window's caption (490 FPS). Sciter Engine (HTML/CSS/script) is fully contained in sciter.dll (4.9 Mb) (https://github.com/c-smile/sciter-sdk/tree/master/bin/32 https://github.com/c-smile/sciter-sdk/tree/master/bin/32) without external dependencies. It works on all Windows versions starting from Windows XP and provides choice of four backends to use: Direct2D (GPU and WARP), Skia (OpenGL and CPU) and GDI+ (just in case someone is still interested in mammoth's shit). On MacOS it uses Skia/OpenGL or CoreGraphics. On Linux it uses by default Cairo (good enough) and Skia/OpenGL as an option.
- sounds 8y ago
  Skia is not a small dependency, FWIW.
  - c-smile 8y ago
    I mean binary dependency here - external DLLs. But in any case I am building sciter.dll as with Skia (sdk/bin/skia32/) as without it (sdk/bin/32/)

lossolo 8y ago

I second this. Some real world comparisons would be indeed great, to see how much lighter it really is. I would also add some heavy page to compare in context of CPU and memory usage between chromium and this framework.

samstave 8y ago

Where can I find the canonical list of how efficiently each tool renders that wiki page, I'd really like to see it?

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 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/master/include/Ultralight/platform https://github.com/ultralight-ux/ultralight-0.9-api/tree/mas...

sesteel 8y ago
Out of curiosity, who is "we"? How big is your team?
- adamjs 8y ago
  The team is currently me :). Will be hiring soon.
c-smile 8y ago
> … HTML UI where the assets are controlled … Real life HTML UI requires a bit more than standard HTML/CSS. At some point you will discover that you will need something like this: elem.popup(popupElem, at) to show arbitrary DOM elements as popup elements (DOM-element-in-its-own-window) like here https://terrainformatica.com/w3/sciter-tooltip.png https://terrainformatica.com/w3/sciter-tooltip.png Yet pure HTML desktop windows: https://sciter.com/html-window/ https://sciter.com/html-window/ with support of Acrylic/Vibrancy: https://sciter.com/sciter-4-2-support-of-acrylic-theming/ https://sciter.com/sciter-4-2-support-of-acrylic-theming/ And at some point you may discover that by adding this to CSS: div.widget { prototype: MyWidget url(/js/widgets.js); } and extending DOM Element by simple elem.merge(newHtml[, callback]) you will have the whole ReactJs thing obsolete/not-needed. All that ... If you want you can contact me so we can discuss all these in details.
derefr 8y ago
> with most memory being allocated by the JavaScriptCore VM If I'm writing a green-field HTML5 app, and I don't derive any benefit from Javascript, is the interface between Ultralight and JavaScriptCore clean enough to just rip out the JS support altogether, replacing it with something simpler? I'm picturing: 1. I embed Ultralight into a process that exposes a simple script-loading API, ala the one in JSCore; 2. I write HTML with no <script> elements, just elements with onclick/ontouch/etc. handler attrs, where these handlers just contain a UUID; 3. Ultralight passes the "script code" (i.e. the UUID) to my trivial script-loading API, which simply looks up a native handler based on the provided UUID, and returns its function pointer; 4. Ultralight holds onto that function pointer and treats it just like a regular thunkable Javascript handler function pointer. In other words, all the "dynamism" of the HTML would be handled by native, static code in my compiled binary, with the only thing being set up at runtime being the binding of DOM elements to those known-at-compile-time native handlers. The QML/XAML/NIB approach.

c-smile 8y ago

Just in case, here is Sciter rendering HTML 3.2 specification document using Direct2D/DirectX backend on 3840x2160 screen: https://sciter.com/sciter-fps/ https://sciter.com/sciter-fps/ Real FPS is shown in window's caption (490 FPS). Sciter Engine (HTML/CSS/script) is fully contained in sciter.dll (4.9 Mb) (https://github.com/c-smile/sciter-sdk/tree/master/bin/32 https://github.com/c-smile/sciter-sdk/tree/master/bin/32) without external dependencies. It works on all Windows versions starting from Windows XP and provides choice of four backends to use: Direct2D (GPU and WARP), Skia (OpenGL and CPU) and GDI+ (just in case someone is still interested in mammoth's shit). On MacOS it uses Skia/OpenGL or CoreGraphics. On Linux it uses by default Cairo (good enough) and Skia/OpenGL as an option.

sounds 8y ago
Skia is not a small dependency, FWIW.
- c-smile 8y ago
  I mean binary dependency here - external DLLs. But in any case I am building sciter.dll as with Skia (sdk/bin/skia32/) as without it (sdk/bin/32/)