I've been working on Yetty, a terminal emulator that uses WebGPU to render not just text, but also images, PDFs, plots, and interactive widgets directly in the terminal grid.
The core idea is "cards" – rich content blocks that occupy terminal cells and scroll with your output, similar to Jupyter notebooks but in a proper terminal. You can display a
matplotlib plot, and it scrolls up with your shell history.
What's implemented:
- MSDF font rendering (crisp at any zoom)
- Bitmap glyphs for color emojis
- Shader glyphs for animated spinners
- Cards: images, PDFs, plots, vector graphics (SVG/Lottie), ImGui widgets
- OSC escape sequences and RPC for card creation
- Builds on Linux (macOS/Windows untested but should work)
What's honest:
- Test coverage is limited (we're moving fast)
- Currently builds with Dawn backend only (wgpu-native may not work)
- It's not a daily-driver replacement for your terminal yet
- Documentation is sparse
Built with libvterm, Dawn/WebGPU, FreeType, msdfgen, and GLFW. MIT licensed.
Looking for contributors and feedback. If you've ever wished your terminal could show inline graphics without hacks, I'd love to hear your thoughts.
GitHub: https://github.com/zokrezyl/yetty (https://github.com/zokrezyl/yetty)
It's fine and thank you! I am playing arround with the idea, in theory all is good.. Only thing is that things like "first non ..." often involve branching that corrupts the prediction ability of the CPU. Therefore I kindly invited you to show it in code.
Thanks for the suggestion. Indeed, that would be the first approach. That is how I started. This is however not considering the state (am I inside a 'statement' or not)
statement meaning string from first non-space till next EOL or EOF.
Problem starts when you need to cover the "corner cases". Without the corner cases the algo is not algo.
For my problem describe under the link above the suggestions above eliminate indeed the branches, but same time the extra instructions slow down the same as my initial branches. Meaning, detecting newlines would work almost 100% of memory throughput, but detecting first non-space reduces the speed to bit above 50% of bandwith
thanks for pointing out! I tried the borrowing trick from the previous segment, was pretty obvious, but for some reason failed as could not avoid at least one conditinonal... will try again.
I do not have one "implementation" but have been trying with different approaches that all delivered under 50% of memory bandwith... I guess if anyone can purpose a solution should be from scratch... The problem is that all approaches I tried end up generating unpredictable branches that do not allow the CPU to optimally keep loading text from memory.