Add render demo to landing page

[ling0x]

Partially addresses #830

Add live rendered TachyonFX demo on the landing page to replace the previous JavaScript version, which is quite slow.
Add label attribution to Ratzilla and WebAssembly.

Preview: https://ratatui.ling.ooo/

Screencast.From.2025-12-29.18-17-07.mp4

[orhun]

Nice, this looks better & works faster than the previous animation for me :)

I will check out on mobile soon

[orhun]

This looks pretty good to me!

The animation is a bit fast and strong.. if we could make it milder then it would be great imo!

[ling0x]

The updates effects can be previewed here: https://ratatui.ling.ooo/

In addition to resolving the above comments, I've also added padding for screens around 1280px width (as reported on Discord) and fixed the horizontal scrollbar issue in Chrome.

The SSL certificate for the Scope TUI showcase link appears to have expired, which caused it to display as blank (we may need to contact the author about this):
https://cdn.alemi.dev/scope-tui-oscilloscope-music.webm

[orhun]

Fading from left to right via black color seems a bit off. Could you maybe disable it or use the same color as the website's background?

[orhun]

I just checked on mobile and it doesn't render for me. Should we switch to another backend maybe? (DOM?)

[ling0x]

Occasionally, the WASM renderer appears blank in Chrome, especially during resource optimization when the browser tab has been left idle for awhile, or on the first load. Firefox doesn’t seem to have this issue. This might be related to how Astro handles WASM rendering. I’ve already tried forcing a reinitialization when a WebGL context loss error occurs. We could test switching to a different backend (e.g., DOM) to see if the problem persists.
@junkdog, is it possible to switch the backend in the TachyonFX renderer?

[junkdog]

or on the first load

can the a context loss happen during first load? sounds unlikely but maybe i'm missing something. if nothing renders on load - in my experience, it's usually a race-condition or crash during init.

reinitialization when a WebGL context loss

the current version of tachyonfx-renderer bundles beamterm 0.8.0 or 0.9.0 - automatic recovery from opengl context loss was added in 0.10.0.

i can release a new version of tachyonfx-renderer during the weekend (prob tomorrow), which bundles the latest beamterm.

is it possible to switch the backend in the TachyonFX renderer

no, it only supports the webgl2 backend.

[junkdog]

btw, if you want to iterate on the effect interactively, you can do it here

[junkdog]

i can release a new version of tachyonfx-renderer

i've released tachyonfx-renderer 0.3.0 - it manages loss/recovery of the opengl context

[ling0x]

Thanks! Updated tachyonfx-renderer to 0.3.0. It now automatically re-renders when a CONTEXT_LOST_WEBGL event occurs, so the canvas no longer appears blank in Chrome. Could someone try this in Chrome and confirm if you see the same behavior?

Steps to test:

1. Open the app in the Chrome browser and observe the initial render for any visual issues or irregularities.
2. Switch to a different browser tab and wait for a few minutes (around 5 minutes perhaps); this should trigger Chrome’s resource management to reclaim GPU resources and clear the WebGL context, which can result in a CONTEXT_LOST_WEBGL warning.
3. Return to the app’s tab and check the browser’s developer console for any CONTEXT_LOST_WEBGL warning messages, and if you don't see the message, try to switch to different tabs and then switch back and check again. You should be expected to see this warning, and then see that the canvas has been immediately re-rendered without being blank.

[junkdog]

you can lose the context programmatically too - it *should* be the same.

// retrieve
const canvas = document.querySelector('canvas');                                                                                         
const gl = canvas.getContext('webgl2');                                                                                                     
const loseContextExt = gl.getExtension('WEBGL_lose_context');

// lose it
loseContextExt.loseContext();

// reinit
loseContextExt.restoreContext();

i tested and confirmed working on chromium 144.0.7559.109 and firefox 147.0.3 (linux, radeon 8060s w wayland).

[orhun]

I think this is almost ready!

I realized a couple of things:

1. On desktop, there seems to be a black background offset around the code area:

On 133% zoom, it is more visible:

I also observed the same behavior on mobile:

Maybe this is related to the recent changes in beamterm, not sure. cc @junkdog

2. Merge conflicts :)

[junkdog]

the padding color, i.e. the area not covered by the terminal, can be controlled with RendererConfig::withCanvasPaddingColor(u32)

i don't think it's the issue here, but depending on how things are setup, there's also RendererConfig::withAutoResizeCanvasCss(bool)

i plan to support the dynamic atlas in the renderer too - which would maintain the scale of font relative to browser font - but there was some sort of impediment which i can't recall at the moment, so i shelved it for later.

[ling0x]

const config = new RendererConfig("tachyon-canvas")
        .withDsl(EFFECT)
        .withCanvas(ANSI_CODE)
        .withCanvasPaddingColor(0x0f172a)
        .withAutoResizeCanvasCss(true);
      renderer = createRenderer(config);

I've tried chaining them, and it doesn't solve the problem.

100% scale (chrome archlinux desktop):

125% scale (chrome archlinux desktop):

I believe the core issue lies in the ANSI code generation process https://github.com/ling0x/ratatui-website/blob/fe44f7e0ae127908fb66b7d2b04c4b1d2c9b6ef4/src/utils/generateAnsiCode.sh#L29 . The ANSI code is currently hardcoded as a static asset with a fixed line width of 66 characters to match the canvas width. When the canvas auto-scales beyond this width, the ANSI code would need regeneration to maintain proper display, which would be impractical to perform dynamically in the user's browser.

Additionally, the rendering appears incorrectly scaled on Windows 11 Chrome with small laptop screens. This seems to stem from Windows' different scaling behavior compared to Linux, combined with the WASM implementation's lack of responsiveness.

100% scale (chrome windows 11 laptop):

I don't think we can solve this responsive scaling problem, including the dynamic adjustment of ANSI line length, purely with JavaScript.

My recommendation is to revert to the JavaScript version of the CodeEffect component for now and merge the remaining changes from this pull request. I've made other improvements to the landing page layout in this PR for better small-screen compatibility and adjusted the showcase tile proportions for improved visual presentation.

[orhun]

I believe the core issue lies in the ANSI code generation process

Ah, right! That makes sense.

My recommendation is to revert to the JavaScript version of the CodeEffect component for now and merge the remaining changes from this pull request. I've made other improvements to the landing page layout in this PR for better small-screen compatibility and adjusted the showcase tile proportions for improved visual presentation.

Sounds good to me. Should we leave this one as is and maybe create a new PR with those related changes then?

[junkdog]

yeah, better do it as a separate PR since everything else is in place + this prob warrants another tachyonfx-renderer release, methinks.

.withCanvasPaddingColor(0x0f172a)

shouldn't the padding color be 0x1D2021?

The ANSI code is currently hardcoded as a static asset with a fixed line width of 66 characters to match the canvas width.

this should be fine, it would/should just leave padding on the right-hand side.

Additionally, the rendering appears incorrectly scaled on Windows 11 Chrome with small laptop screens.

hmm, i think what we're seeing is the snapped scaling behavior for the static font atlas (which should be covered by the padded color - but i can check if there's something off after recalculating the DPR). tachyonfx-renderer has to support the dynamic atlas to maintain size and scale the font along with the browser zoom.

[ling0x]

Done.

#1071