Bloomberg Terminal, how I would do it with Sciter.

I think the image above looks familiar to people working around stock exchange.

The screen contains many areas that are updated in real time so it is interesting to try to implement this using Sciter and its rendering pipelines.

So I’ve made simple mockup of typical screen used there, in particular that scrollable list with the data that is updated each 40ms (25 times per second).

The demo with binaries and the sample source is part of SDK (sdk/samples/+vlist/bloomberg-terminal/) and is available here.

The demo features two functionalities that are measured in Sciter full screen on high-dpi 3000×2000 monitor:

• Kinetic (animated) scroll of the recordset with 60 FPS update frequency: CPU consumption on my machine is 10 – 12%
• Live recordset update – 10 records mutated each 40ms ( 25 times per second ): CPU consumption is around 2%.
• GPU consumption is also quite low, around 1.2%

The demo is using scrollable table ( that’s Sciter unique feature ) in virtual list mode:

1. Number of DOM elements reflects visible area and is around 20columns x 43rows = 900 DOM elements.
2. Sciter allows to transform any DOM element into <input> or <output> and so, by assigning td { behavior: output } to <td> elements, I am minimizing number of DOM elements needed to represent the screen significantly (2-3 times less if to compare with typical browser based solution).
3. I’ve tested that file in DirectX mode tool that allows to update the screen with max frequency and getting 200-250 FPS update frequency. Normal mode (that exe in the archive) updates the screen on WM_PAINTs that are coming with 60 FPS max (VSYNC frequency actually).

All the above is just an illustration of different approach used by Sciter to achieve responsive HTML/CSS based UIs:

Instead of fighting with limitations of browsers and their monstrosity Sciter offers real embedabilty:

1. You don’t need full scale browser packaged into Electron ( 200mb of binaries) or whatever to achieve performant solution. 5mb of sciter.dll is quite adequate for that.
2. Script in UI is
   • a glue connecting output of one native function with input of another. In order to achieve performant solution you’d better to provide native function that does mission critical thing. You simply don’t need to support JIT or WebAssembly infrastructure for all that. Use you favorite C++ IDE, tools it provides and tons of libraries that are already there. It is just plainly stupid to do ray-tracing in the language (JavaScript) that was simply not designed for such tasks.
   • script uses GC to manage ownership graphs with loops that UI is famous for. Scripting (GCable environment), and Sciter’s Script in particular, is the most adequate language for the language-behind-UI tasks.
3.  If you experience bottlenecks in some of your UI areas you shall use embeddable and extendible engine (the Sciter) where you can easily implement critical algorithms in native code (e.g. C++) while keeping same level of flexibility of HTML/CSS UI architecture.