8 ms·

Show HN: Inlyne, a GPU powered, browser-less, Markdown previewer

25 points by trimental 4y ago

Markdown files are used universally in almost every git repository and yet you need a browser or electron app like VS Code to quickly open one. To help this I'm trying to create a markdown viewer that renders on the gpu without needing a browser. If this interests you please help try out `cargo install inlyne`. Using it is as simple as `inlyne README.md` and you can set themes, fonts and scaling as you'd like.

anaganisk 4y ago
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?
- trimental 4y ago
  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.
  - anaganisk 4y ago
    Gotchu thanks for the reply!
- SahAssar 4y ago
  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 https://sw.kovidgoyal.net/kitty/#design-philosophy ) so why not this?
  - imran0 4y ago
    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.
    - trimental 4y ago
      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.
boywitharupee 4y ago
Which font rendering technique are you using? Are the layouts computed on the gpu?
- trimental 4y ago
  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.
msravi 4y ago
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...)
- trimental 4y ago
  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 :)
- maujim 4y ago
  > 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/ http://127.0.0.1:44205/` fails [1] https://github.com/euclio/vim-markdown-composer/blob/master/doc/markdown-composer.txt#L16 https://github.com/euclio/vim-markdown-composer/blob/master/...
  - trimental 4y ago
    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.

25 points by trimental 4y ago

anaganisk 4y ago

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?

trimental 4y ago
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.
- anaganisk 4y ago
  Gotchu thanks for the reply!
SahAssar 4y ago
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 https://sw.kovidgoyal.net/kitty/#design-philosophy ) so why not this?
- imran0 4y ago
  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.
  - trimental 4y ago
    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.

boywitharupee 4y ago

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

trimental 4y ago
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.

msravi 4y ago

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...)

trimental 4y ago
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 :)
maujim 4y ago
> 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/ http://127.0.0.1:44205/` fails [1] https://github.com/euclio/vim-markdown-composer/blob/master/doc/markdown-composer.txt#L16 https://github.com/euclio/vim-markdown-composer/blob/master/...
- trimental 4y ago
  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.