Lite XL UIs

[takase1121]

Lite and by extension Lite XL's design meant that it's possible to implement alternate UIs. Compared to Neovim's IPC approach (which has it's own benefits), one simply need to implement renderer module to create an alternative backend.

Examples:

• rxi's original renderer - it is possible to backport this for lite XL, but of course you lose everything Lite XL offers in term of font rendering
• @adamharrison's renderer - it's still WIP and can be found here: Simplifying the Font Renderer #409
• (sorry for self promotion) nanovg renderer - it's a PoC that I created to investigate OpenGL acceleration. It's available here
• Lite XL's SDL renderer - this is only used on MacOS for some reason, but it should work regardless of platforms.

Ideas worth investigating

• TUI renderer - possible, but some keys won't work
• headless renderer - sending draw commands over a socket? That seems interesting, especially with WSL

Maybe someone else would have more ideas about this.

[vincens2005]

electron.js based renderer /s

maybe a vulkan-based renderer?

[takase1121]

nobody said you can't just compile Lua to wasm and implement renderer with canvas webGL

[vincens2005]

maybe...

[franko]

Very nice topic, thank you @takase1121 for bringing this discussion..

I am personally interested in:

• let lite-xl renderer actually don't use opengl, that is a very important matter but is neglected. It require some hard-work and hard skills about opengl and it is not fancy but is really important
• backport the work of @adamharrison on lite-simplified into lite-xl itself.
• pursue the work I initiated on rencache-texture branch to improve the performance on scrolling. Today lite-xl is very dumb about that. I had some discussion with @adamharrison and he may work on that or not I don't know. Once again this is not fancy, just hard work to implement an important performance improvement that wound be key for lite-xl for the next 10 years.
• headless rendering, very useful for automated tests

For opengl I mention the hard skills and the hard work because it is difficult to find people with the required skills and it is difficult to find someone willing to do the difficult work.

The lite-xl SDL renderer is just about how you put your big pixel image of the whole application to the screen so that's not a big deal. It is just needed for macOS to support retina displays using SDL APIs.

I like when people experiment with new ideas but please consider also using a part of your time to work on what is important to put the project forward.

NanoVG is cool to thinker with, really, but the project is abandoned, libagg already provides SVG capabilities with paths of any kind and is already integrated in lite-xl. In the meantime we are still not using opengl as we should to render stuff in lite-xl. The interest I see in NanoVG is as a test bed to experiment using opengl for rendering.

electron-js doesn't make a lot of sense to me because you will be bloated like vscode or atom and missing most of the things they have. It is certainly not me who will be working on this subject.

What about vulkan ? well we are not even using opengl so we should first start with opengl right ? once openGL is in the transition to vulkan should be pretty straightforward I guess.

Just to clarify, when talking about using opengl or vulkan it is important to make the difference about how it is used. OpenGL can be used just to put the things on the screen but you have little gain to use it if all the pixels rendering for the application window is done one the CPU.

[takase1121]

electron-js doesn't make a lot of sense to me because you will be bloated like vscode or atom and missing most of the things they have. It is certainly not me who will be working on this subject.

yes, the Electron backend was just a joke.

---

NanoVG is cool to thinker with, really, but the project is abandoned, libagg already provides SVG capabilities with paths of any kind and is already integrated in lite-xl. In the meantime we are still not using opengl as we should to render stuff in lite-xl. The interest I see in NanoVG is as a test bed to experiment using opengl for rendering.

I agree. After working on my PoC, I realized NanoVG's rendering can't match the original renderer. That's why I didn't bother submitting it to anyone.

---

What about vulkan ? well we are not even using opengl so we should first start with opengl right ? once openGL is in the transition to vulkan should be pretty straightforward I guess.

I don't see this coming anytime soon.

---

The lite-xl SDL renderer is just about how you put your big pixel image of the whole application to the screen so that's not a big deal. It is just needed for macOS to support retina displays using SDL APIs.

This can be accelerated AFAIK with SDL_RENDERER_ACCELERATED. Since the software renderer (non-SDL) achieve the same thing, I don't see the reason of keeping the software renderer and instead use SDL.

---

Just to clarify, when talking about using opengl or vulkan it is important to make the difference about how it is used. OpenGL can be used just to put the things on the screen but you have little gain to use it if all the pixels rendering for the application window is done one the CPU.

This is exactly what I found out with my PoC. The CPU reduction is negligible (at most 4% when scrolling really fast). This shows that we spend way more time in Lua than actually rendering something.

---

For other backends (GL, DX, Vulkan), perhaps one can consider bgfx. But really - we're here to make Lite XL, not Heavy XXXL.

[takase1121]

This can be accelerated AFAIK with SDL_RENDERER_ACCELERATED. Since the software renderer (non-SDL) achieve the same thing, I don't see the reason of keeping the software renderer and instead use SDL.

Disregard this - in this case the hardware acceleration works against the rendering process, making it twice as CPU intensive (tested on my computer)

[mundusnine]

Indeed, something like bgfx would make things hefty. I personally use Kinc which could replace SDL for the input and cover the cross-platform GPU accelerated rendering.

For font rendering and simplifying the whole codebase I would probably use dear imgui with Kinc and expose to users the high level dear imgui calls. If this would be interesting for the project, I could dedicate some time to this.

On a personal note, it would alleviate the process of helping for development as for Kinc no need to use something like meson as it offers a custom solution for project generation that's included in the git of the project itself so no need to install anything just git clone --recursive and you can't start working on the project(well if you have an IDE installed as it will generate project files for Visual Studio, codeblocks or Xcode).

Just an FYI, samples of dear imgui kinc are available

This would be a huge rewrite though.