Screens/Screens you have to keep feeding/RGB timing
Lesson 9 of 16 · in 3D and VR

RGB timing

A parallel RGB screen is sent colours plus four timing signals, and the timing is what places the colours. Change a porch by a few clocks and the whole picture slides across the glass, although every pixel value is still correct.

Lonely BinaryUpdated 2026-10-014 min readNo board required

View it in VR

Lesson 9 of the Screens course opens in a VR headset, on a table in front of you, and a voice starts three seconds after you arrive. Type this short address into the browser on a headset such as Meta Quest or Apple Vision Pro, and press Enter VR. No headset? Press Start the lesson: the same lesson, full screen.

learn.lonelybinary.com/vr/screens/9

A parallel RGB interface is the stream type from lesson seven made literal. The host puts one pixel on the data lines per pixel-clock tick and never stops. Four signals say where those pixels belong: PCLK, the pixel clock; HSYNC, which marks a line; VSYNC, which marks a frame; and DE, Data Enable, which is high while the values on the data lines are real pixels.

On the ILI9341, which is our example controller, the data is sampled on the rising edge of the pixel clock. A host that changes the data on the wrong edge gives the panel values that are still moving when it samples them.

Two ways to say where the picture is

In DE mode the controller needs only DE. The picture starts where DE goes high, and the porches are implied by where it does. In sync mode DE is ignored and the position comes from HSYNC and VSYNC plus porch values that are programmed into the controller.

Around the active pixels sit the intervals that look empty: the sync pulse, the back porch before the picture, and the front porch after it. They carry no colour and they have real parameters. In ESP-IDF they are fields of the RGB timing structure next to the PCLK frequency, and the numbers come from the panel's datasheet, not from the host.

What a wrong porch costs

Lengthen the horizontal back porch and the picture starts later in every line, so it moves across the panel. Lengthen the front porch and the active pixels stay where they were, but the line becomes longer, the frame takes longer, and the refresh rate falls. Neither changes a pixel value.

The names come from analogue television, where the cathode-ray beam was switched off while it flew back to the next line. Digital panels kept the parameters and they are still specified.

On the ESP32

The ESP32-S3 has a parallel RGB path on its LCD_CAM peripheral, with 8 or 16 data lines. Bus width and pixel timing are separate choices. The classic ESP32 has no RGB peripheral, and the ESP32-P4 has one as well as DSI.

Common mistakes

  • Expecting the screen to know where a line begins. Correct pixel values are not enough. Without the right sync and porch values the picture can be shifted on the glass.
  • Treating every RGB screen as memoryless. The ILI9341 writes incoming RGB data into its own GRAM before it drives the panel. Some controllers can bypass it, and it is a register choice.
  • Copying porch values from another panel. They belong to one datasheet. The same pixel clock with another panel's porches is one possible cause of a shifted picture.

Edit this page — content/fundamentals/screens/rgb-timing.mdx

Discuss this article

Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.

Browse Fundamentals on the forum →