Expose JPEG decoder timeout_ms as a configurable parameter (ESP32-P4)

[jkc123go-dev]

Summary
On an ESP32-P4 (CrowPanel Advanced 10.1", engineering-sample silicon), JPEG tile decoding is consistently slow and dominated by repeated internal decoder timeouts — even against the built-in self-test page. This makes scrolling through a real Home Assistant dashboard extremely sluggish (multi-second delay per scroll movement) and produces visible corrupted/discolored tile artifacts that persist until overwritten by a later update.
I'd like to request that timeout\_ms for the JPEG decoder engine be exposed as a configurable YAML parameter, the same way jpeg\_quality and max\_bytes\_per\_msg already are.
Environment
Board: Elecrow CrowPanel Advanced 10.1" (ESP32-P4 + ESP32-C6 co-processor)
Chip: ESP32-P4 rev1.3, engineering\_sample: true
ESPHome: 2026.8.2
ESP-IDF: 5.5.5
remote_webview component: pulled from github://strange-v/RemoteWebViewClient@main
Display: 1024x600, MIPI-DSI, hw\_jpeg: yes
Symptom
Individual tile decodes routinely hit an internal timeout and appear to retry multiple times before eventually succeeding, resulting in a consistent ~1600ms per-frame completion time even for small partial updates. This happens:
On the built-in self-test page, not just real dashboard content
Regardless of jpeg\_quality, max\_bytes\_per\_msg, tile\_size, min\_frame\_interval, or big\_endian settings (see "Already tried" below)
Most visibly during scrolling, where the rapid sequence of partial updates makes the slowdown and artifacts obvious, though the same underlying decode timeouts are present at idle too
Log excerpt

\[03:35:55.979] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout, please check image accuracy and `timeout\_ms`
\[03:35:56.226] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:56.533] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:56.747] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:56.791] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:57.045] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:57.158] D Remote\_WebView: frame 60: tiles 18 (27171 bytes) - 1623 ms
\[03:35:57.200] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:57.459] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:57.602] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:57.804] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:58.069] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:58.214] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:58.478] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:58.621] E jpeg.decoder: jpeg\_decoder\_process(322): jpeg-dma2d handle jpeg decode timeout...
\[03:35:58.621] D Remote\_WebView: frame 61: tiles 18 (27164 bytes) - 1623 ms

Note frames 60 and 61 both complete in almost exactly 1623ms despite slightly different byte sizes — this looks like it's hitting a fixed ceiling rather than varying organically with content complexity.
Already tried (none resolved it)
jpeg\_quality: 85 → 75
max\_bytes\_per\_msg: 14336 → 61440 → 102400
min\_frame\_interval: 80 → 40 → 120
big\_endian: true → false (changed artifact color from pink to gray, did not eliminate them)
full\_frame\_tile\_count: left at 4, have not yet tried 1
The actual ask
Espressif's own ESP-IDF docs for jpeg\_new\_decoder\_engine() show a reference timeout\_ms of 40, with the note that this "should be larger than valid decode time." That's a very tight ceiling for real-world content (icons, text, gradients) versus simple test patterns, and may be too aggressive for this specific engineering-sample silicon's JPEG-DMA2D peripheral.
Rather than asking for a fix to the underlying hardware/timing behavior (which may not be practical without the exact board in hand), I'd like to request timeout\_ms be surfaced as an optional YAML parameter on remote\_webview, alongside the existing jpeg\_quality and max\_bytes\_per\_msg options — so users hitting this on specific hardware can raise it themselves without needing a component change per board.
Happy to test a build with this exposed and report back results if that's useful.