sciter-sdk

Not exactly. I am building HTML-NOTEPAD (https://html-notepad.com) from the same sources ( https://github.com/c-smile/sciter-sdk/tree/master/notepad ) for all desktop platforms. It uses sciter (https://sciter.com) which is sort of micro-electron if you wish. Distribution of the app is 2mb rather than 200mb.

Check this sample : https://github.com/c-smile/sciter-sdk/tree/master/samples/id... in SDKs sciter.exe. That is tray notification. As of menu: sdk/samples/menu

Sciter's API is already simple enough. It is about 10..20 pure C functions that you will use for creating window, loading UI resources and receiving callbacks from the UI. Check minimal integration sample: https://github.com/c-smile/sciter-sdk/blob/master/demos/mini...

Here is "DOM canibalizer" module from my HTML-NOTEPAD ( https://html-notepad.com ) : https://github.com/c-smile/sciter-sdk/blob/master/notepad/re... While it looks pretty simple it cleans MS Word and browser artifacts in pasted markup pretty well. But I shall admit that such simplicity is possible only with sciter (that html-notepad is based on). E.g. that canonicalizeDOM gets called before the content appears in target document. So all this does not affect undo/redo stack, etc.

So they added Span<T> as a big thing ... > (Span<T> is) at the heart of most performance-related improvements in .NET Core 2.1. Since it allows managing buffers in a more efficient way, it can help in reducing allocations and copying. We consider Span to be a very fundamental type as it requires runtime and compiler support in order to be fully leveraged. Small struct that is declared as public readonly ref struct Span<T> { private readonly ref T _pointer; private readonly int _length; ... } which is exactly what I am using in Sciter (https://sciter.com) for 10+ years: template <typename T> struct slice { const T* start; unsigned int length; ... } https://github.com/c-smile/sciter-sdk/blob/master/include/au... Such small thing definitely speed ups many ar

Just in case you can do that with Sciter already. In your CSS to define div.my { behavior:my-widget; } While loading HTML that contains <div class="my"> you will get SC_ATTACH_BEHAVIOR callback with the DOM event handler reference. By handling SC_ATTACH_BEHAVIOR you will return DOM event handler (a.k.a. behavior) - just a native function pointer that receives all DOM events on that element: mouse, keyboard, etc. That's the same mechanism as HWND and WndProc but with lightweight DOM elements instead of Windows. Example of such behavior that implements panels with tabs container: https://github.com/c-smile/sciter-sdk/blob/master/include/be...

Just in case, here is Sciter rendering HTML 3.2 specification document using Direct2D/DirectX backend on 3840x2160 screen: 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) 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.

70MB is too much for mainly native application. For the comparison, IDE sketch (editor with syntax highlighting) from Sciter (HTML/CSS/script engine) SDK (https://github.com/c-smile/sciter-sdk/tree/master/samples/id...) takes 43 MB. Screenshot: https://sciter.com/wp-content/uploads/2018/05/idea-ide.png

Let me know if you need more tests around this. If to consider more complex DOM cases then you can try https://notes.sciter.com/ application. Or to run it from SDK directly: https://github.com/c-smile/sciter-sdk/blob/master/bin/32/not... Notes window layout resembles IDE layout pretty close. And Notes works on Window, Mac and Linux so you can compare different native text rendering implementations (I mean without conventional browsers overhead).

"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter (https://sciter.com)... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen text rendering on DirectX surface using Direct2D/DirectWrite primitives. Display is 192 ppi - 3840x2160: https://sciter.com/temp/plain-text-syntax.png On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample. CPU consumption is 6% as it constantly does rendering in a "game event loop" style. In reality (render on demand as in sciter.exe) CPU consumption is 3% on kinetic scroll (12