What the FOUC? Fixing Layout Jitter on Smart TVs

In the world of high-end UI, there's a ghost that haunts even the fastest applications. We call it FOUC: Flash of Unstyled Content.

On the web, you've seen it when a page loads: a split second of raw HTML before the CSS snaps into place. But on TV, FOUC takes on a different, more jittery form. Nothing is missing; the UI is simply "thinking out loud."

• A button renders at a default size, then adjusts to fit the text.
• A list shifts down a few pixels as a header settles.

On a 6-inch phone, you might miss it. On a 65-inch 4K display in your living room, it's impossible to ignore. It looks like a mistake, even when the code is technically correct.

The "Visual Negotiation"

Why does this happen? It's a side effect of how rendering engines traditionally resolve layout. When building the Flex system for the Solid + Lightning 3 integration, the goal was to make layout effortless, declarative, predictable, and intelligent.

But that intelligence often requires a "conversation" between the framework and the renderer:

1. Draw: The UI is painted.
2. Measure: The Renderer calculates actual text dimensions.
3. Correct: Layout shifts to accommodate those dimensions.

That negotiation happens in front of the user's eyes. In the race for speed, certainty gets sacrificed. We push frames quickly, even when the first one isn't truly ready.

The Button Example

Below we have a simple button using flex.

Below are the steps that happen to lay out the result on the right:

1. Set default width = width of the parent, which may be up to 1920px wide.
2. createNode and render → draws an "incorrect" frame.
3. Text information is reported back, layout is calculated.
4. New layout → Renderer draws a new frame.

Quality Isn't a Tradeoff

There's a common trap in performance engineering: the assumption that hitting 60 FPS means you've won. But frame rate alone doesn't define quality.

If the first frame feels unstable, the experience feels cheap.

On a large screen, even tiny shifts break immersion. They erode trust. They make a polished product feel like a prototype. The key insight? We don't actually have to choose between speed and stability.

Fixing It at the Root: Atomic Rendering

In the Solid + Lightning 3 integration, the negotiation now happens entirely behind the curtain. By ensuring text measurement and Flex recalculations resolve before any WebGL draw calls are issued, we achieve what I call Atomic First Paint: a frame that appears fully resolved the moment it's shown.

• No layout-hiding hacks.
• No pixel nudging.
• No visual jitter.

Best-in-Class by Default

The goal for SolidTV has always been simple: deliver the best possible experience for both the developer writing the code and the person holding the remote. Flex made building UI modern and intuitive; Atomic Rendering ensures that apps don't just run fast — they feel deliberate and polished.

Let's Raise the Standard

I want SolidTV to be the most reliable way to build for the big screen, but "best-in-class" is always moving. To get there, we need to surface real-world friction together.

• Are you seeing other forms of visual jitter?
• Where are you still writing workarounds to hide engine behavior?
• What challenges are you still facing?

If you want your TV apps to feel better for users and simpler to build, get in touch. I'd love to connect.

• Official Website: solidtv.dev
• GitHub Repository: github.com/solid-tv/solid
• Community Discord: Discord
• Connect with Me: Chris Lorenzo on LinkedIn

Originally published on JavaScript in Plain English.