I’m just curious as to what GPU helps with for rendering plain html/markdown? What huge numbers is it crunching to render say a markdown file vs a 3D scene? Also browser doesn’t render MD right? All browser based implementations are done in JS or server side so what does it mean when its browserless?

Thanks for the question. Markdown files are basically html files with syntax sugar, and a lot of markdown files directly use html. So to properly render most files you need a basic html renderer at minimum. Although yes, you don't need the other features of a browser but typically most markdown renderers are either web-based (GitHub) or electron based (VS Code).

GPU rendering helps for scaling images, rendering text and drawing other primitives efficiently. It frees up CPU time, and can redraw many times faster in scrolls and resizes. This is why most browsers use the GPU when most web content is 2D. GPU's don't really crunch huge numbers but instead utilise parallelisation.

Gotchu thanks for the reply!

Most graphical markdown renderers seems to convert markdown to html and then render that html using a browser engine. This includes basically any based on electron (vscode, atom, obsidian, roam) and a lot of others that do it via platform web views.

The point of the browser-less claim is that it converts the md to html the same way most existing engines do, but then does not use a browser engine to render it, instead using something faster and more purpose-built.

As for the GPU-thing I'm not sure, but for example terminals are sometimes written to take advantage of GPU's (kitty for example: https://sw.kovidgoyal.net/kitty/#design-philosophy ) so why not this?

Something like a simple markdown renderer has little reason to use the GPU. But a terminal emulator has absolutely no reason to use one. The bottlenecks there are system I/O and legacy API's, not the rendering performance.

The terminal statement is false. In fact I contributed an Alacritty feature that stopped rendering when the window was occluded that cut CPU usage from ~10% to ~0.4% when not visible. There's also a misconception on what GPU's are useful for. Being the graphics processing unit they are much faster for processing images and glyph graphics then the cpu.

Very cool! The rendering looks great! A wishlist:

1. Rendering of LaTeX equations

2. Vim keybindings (/ for search, ^F/^B for PgDn/PgUp, etc.)

3. Should work with vim markdown composer (by setting g:markdown_composer_browser = 'inlyne' - not sure why this just doesn't work now...)

> not sure why this just doesn't work now

markdown-composer passes a uri to the program. [1]

You can see the uri by setting `g:markdown_composer_browser = 'notify-send'`

inlyne expects a file so `inlyne http://127.0.0.1:44205/` fails

[1] https://github.com/euclio/vim-markdown-composer/blob/master/...

Just a little update on this PR #34 adds live reloading of files. I was considering adding support for vim-markdown-composer but its now easy to just `inlyne README.md` and have it automatically update as you write instead.

Thanks for this. It's great to get suggestions on improvements.

LaTex rendering might be very easy or very hard depending on the rust ecosystem for it, so I'll look into that. And I'm not too surprised it doesn't work with vim markdown composer but if it's a simple enough mechanism it'd be a great feature. Vim bindings could very easily be done though :)

Which font rendering technique are you using? Are the layouts computed on the gpu?

Glyph rendering is done (through a rust crate called ab-glyph) by computing glyph vertices on the CPU, and then rendering and storing the glyph textures to the gpu. Layouts are calculated on the CPU.