Announcement

SolidTV Renderer 2.0 Alpha: Rebuilt From Scratch, Same API

By Chris Lorenzo · Published October 4, 2026 · Updated October 5, 2026 · 8 min read

I'm getting ready for Solid 2.0, and I decided to start at the bottom of the stack. Before changing anything in the framework, I rewrote the renderer underneath it from scratch, using AI to optimize every part of the code. SolidTV Renderer 2.0 is now in alpha, and the first device results are in: on an older LG TV running Chrome 38, it doubles the frame rate of 1.x on a heavy stress scene and loads scenes about four times faster.

The API is the one you already know. Almost everything under it is new. TV apps run on chips with a fraction of a laptop's power, so v2 is built around where that hardware loses frames: garbage collection pauses, work spent on nodes that didn't change, and image uploads that land in the middle of an animation.

Why rewrite it now?

Solid 2.0 is coming, and its new reactivity model lines up well with how a TV scene graph wants to update. I want the renderer ready for it. The 1.x renderer started as a fork of the LightningJS renderer, and earlier this year I doubled its FPS by fixing bugs, cutting garbage and caching aggressively. That got a lot out of the existing design. Going further meant changing the design itself.

Not long ago, a ground-up renderer rewrite was a months-long project for a team. With AI it became something I could take on myself, and do carefully. The work started from a written design spec and a phased plan. Every task was written test-first, and each phase had to match 1.10's output in visual regression tests before the next one began. From the first design doc to a working alpha took about a week.

First results on real TVs

Today I ran the alpha on hardware for the first time, against 1.10 on two LG webOS devices:

Both versions ran the same test pages, taking turns going first, with a fresh page load for every run. No run failed or logged a page error. On the older TV:

Redraw FPS, 400 cards

2× 8 → 15.6 FPS

Scene load time

~4× faster

Cards loaded within 1 second

75 → 400

Node creation, warmed up

7.9× faster

And side by side:

v2 against 1.10 Older LG TV
Chrome 38
LG monitor
Chrome 108
Node creation, first pass 3.1× faster 3.6× faster
Node creation, warmed up 7.9× faster 7.4× faster
Scene load, same number of cards ~4× faster ~4× faster
Redraw FPS, 400 cards with text 2× (8.0 → 15.6) Tie (24.9 → 25.0)
Redraw FPS, 400 cards with images 1.6× (14.7 → 23.0) Tie (28.1 → 28.6)
Redraw FPS, 800 cards with text Not run 5% slower (13.9 → 13.2)
Main thread busy per frame, 800 cards Not traced Half (40.0 → 20.7 ms)

Medians of five runs per version (three for the image-only redraw). Each card has a rounded background and an image thumbnail; the text cards add a title and a subtitle. "Cards loaded within 1 second" is the largest grid of text cards that builds and settles in under a second.

What the numbers say

Wherever the renderer's own JavaScript is the work, v2 wins on both devices. Creating nodes is 3 to 4 times faster on the first pass and 7 to 8 times faster once the engine warms up, and scenes load in about a quarter of the time, on the old engine and the new one.

Redraw speed depends on the device's bottleneck. On the older TV the main thread limits the frame rate, so v2's leaner frame doubles it, on exactly the kind of hardware where TV apps hurt most. On the monitor, a Chrome trace shows the browser's GPU thread busy for 99% of every frame in both versions, running the same GL commands. Lighter JavaScript can't buy more frames there.

Even where FPS ties, v2 gives the main thread back. At 800 cards on the monitor, the main thread is busy for 20.7 ms of each frame on v2 against 40 ms on 1.10, and garbage collection drops from 0.8 ms a frame to 0.1 ms. That's time your app gets back for its own work, like responding to key presses.

Not everything is a win yet. At 800 cards on the monitor, v2 is 5% slower than 1.10, most likely because it re-uploads every visible glyph each frame. Uploading only what changed should close the gap.

The lesson for any TV app: find the bottleneck thread before you optimize. Leaner JavaScript doubled one device's frame rate and did nothing on the other. It's the first thing I check in a performance audit.

These stress scenes are far heavier than a real app's screen, so the FPS shows each device's bottleneck, not what your app will see. And the LG monitor isn't a TV, though it runs a current webOS release.

Against LightningJS 3.5.1 on their benchmark

I also ran v2 through the LightningJS benchmark, against the upstream Lightning renderer 3.5.1. Lightning ran the benchmark's renderer harness unmodified, and v2 ran a port of it that changes only the API calls. The benchmark runs on a laptop with the CPU throttled six times, so these are desktop numbers, not TV numbers.

v2 is the fastest on every test. On the benchmark's weighted score, where 1.00 means fastest on every test, v2 scores 1.00 and Lightning 3.5.1 scores 2.24.

Test (ms) Lightning 3.5.1 SolidTV v2 v2 vs Lightning
Create 1,000 rows 32.2 8.5 3.8×
Update all 1,000 rows 26.9 6.8 4.0×
Update every 10th row 25.5 3.3 7.7×
Select a row 26.4 2.5 10.8×
Swap 2 rows 26.3 2.5 10.6×
Remove a row 16.5 2.2 7.4×
Create 10,000 rows 85.8 30.3 2.8×
Append 10,000 rows 99.7 41.1 2.4×
Clear the rows 19.0 1.1 17×
Memory test: 20,000 nodes 257
draws nothing
61.5
draws all
4.2×
Memory test: JS heap (MB) 24.4 5.5 4.5×
smaller
JS bundle (kB) 179.0 153.8 14%
smaller

Times in milliseconds unless noted, mean of three interleaved rounds; lower is better. Chromium 153 on an Apple M4 Pro laptop with a 6× CPU throttle. To draw the same picture as Lightning, the v2 harness gives each row a zIndex, which costs v2 1 to 2 ms a test.

And it's still getting faster. Memory-layout changes on October 5 packed most of each node's data into two contiguous records, which made the node-heavy tests 21% to 41% faster in a day. They landed after the LG runs above, so the devices will be the real test.

What's new

No breaking changes for your app

This was a hard requirement. Apps built on SolidTV's <view> and <text> keep their code as it is. The node props, animations, shaders and events are the ones you use today, and a matching @solidtv/solid release will move to the new renderer, so upgrading should be a version bump.

One thing to check first: v2 draws text only with SDF fonts, so every font your app uses needs an SDF atlas. If you already use SDF fonts, there's nothing to change.

v2 also keeps the same reach as 1.x: Chrome 38 and up. The older LG TV in the tests runs Chrome 38, and v2 ran there without a single page error. That covers the same Tizen, webOS, Android TV, Fire TV and set-top box browsers you ship to today.

How it's tested

Alongside the device runs, the alpha has about 1,500 unit tests, each run in two build configurations, plus 184 visual regression snapshots. Allocation tests hold each scene to a per-frame byte budget, so the garbage collection gains can't quietly regress.

What's next

Device testing has started, and the results set the list:

The beta follows once those hold up, and after that comes Solid 2.0 itself. Doubling the frame rate on a Chrome 38 TV on the first day of device testing is a good start, and I'm excited to keep pushing.

Want to test it early?

If you ship a web-based TV app and want to try 2.0 on your own devices, or you'd like help planning the upgrade, get in touch. I'd love feedback from teams running on real hardware.

Planning a renderer upgrade?

I help teams move TV apps to SolidTV and get them running fast on real hardware: performance audits, migrations from LightningJS, and commercial support for teams shipping on Tizen, WebOS, Android TV, Fire TV and Apple TV.