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:
- An older LG TV: webOS 3.8, Chrome 38, two CPU cores and a 720p panel. Exactly the kind of device TV apps struggle on.
- A newer LG smart monitor: webOS 9.1, Chrome 108, four cores and a 4K panel.
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
- A data-oriented core. Node state lives in typed arrays, and each node is a single small object on the heap instead of about 30. A steady frame allocates 30 to 120 bytes, against up to 74 kB on 1.10. Less garbage means fewer collection pauses on low-memory TVs.
- One pass per frame. Update, culling and drawing happen in a single walk of the scene, and off-screen branches are skipped entirely.
- A loop that sleeps. 1.x kept polling for work even when the screen was still. In v2, a screen where nothing changes draws nothing and does nothing.
- Images load by visibility. What's on screen loads first, then what's just off it. Loads are cancelled when you scroll away, and GPU uploads are paced per frame so they don't hitch an animation.
- Shaders written for the weakest GPUs. The built-in shaders follow Mali-400 rules: 16-bit-safe math and no per-pixel branching.
- One rendering path. v2 renders with WebGL only, and text always uses SDF fonts and is always batched. Dropping the Canvas2D backend removed a whole second code path to maintain and test.
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:
- Fewer GL calls per card. Each card costs two draw calls and two texture binds, and on the monitor those saturate the GPU thread. Batching images through a shared texture would cut both.
- Upload only the glyph data that changed. This should win back the 4.5 ms a frame on the older TV and close the gap at 800 cards on the monitor.
- The LG devices again, with the new memory layout.
- A full app on a reference TV. The solid-demo-app benchmark, 1.10 against v2.
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.
- Renderer:
@solidtv/renderer - Framework:
@solidtv/solid - Docs: solid-tv.github.io/solid
- GitHub: github.com/solid-tv/solid