PS5-style UI: backdrop blur, time-based animation, and two new theme elements

[danielnuld]

What this is

An additive PS5-style visual language for OPL: backdrop blur ("frosted glass"), a real animation engine, three new theme element types, and an included PS5 theme that composes them.

Nothing is rewritten. OPL already had everything needed — gsKit, FreeType, a data-driven theme system, cover art downloading. This grafts onto that.

No existing theme changes. The new element types are appended to the end of elementsType[]; nothing is reordered. A theme that doesn't name them doesn't instantiate them, and — importantly — doesn't even reserve the blur's VRAM: rmBlurInit() allocates nothing, and the chain is claimed lazily on the first rmBlurBackdrop().

The interesting part: blur without shaders

The GS can sample its own framebuffer and chain bilinear taps. A reduction pyramid plus ping-pong passes gives a gaussian-ish blur for a fraction of a frame. No shaders required.

Three things that are easy to get wrong, and cost real debugging:

1. Render target widths must be exact multiples of 64. gsKit writes a buffer with FRAME.FBW = Width / 64 (truncating) but reads it back with TEX0.TBW = ceil(Width / 64). A 160-wide RT is written at a 128-texel stride and sampled at 192: torn. The chain uses 320 and 128.
2. RTs must be GSKIT_ALLOC_SYSBUFFER. FRAME.FBP addresses VRAM in 8192-byte units; USERBUFFER only aligns to 256, so the base address would be truncated and the GS would draw somewhere else.
3. gsKit_setactive() emits FRAME immediately — it does not queue it. The draw queue has to be drained with gsKit_queue_exec() before every target switch, or queued primitives land in the new target.

New API

• rmBlurBackdrop() / rmDrawFrosted() in renderman (the chain itself is isolated in src/rmblur.c — it repoints FRAME mid-frame, which is the most invasive thing here, so it stays behind the narrowest surface that works)
• src/uianim.c — time-based easing. The 1 - exp(-rate*dt) form is what makes it framerate-independent: two 8 ms steps land exactly where one 16 ms step does. Frame-indexed easing would run 20% slow in PAL.
• FrostedPanel, CardShelf, CoverWallpaper theme element types
• texLoadCover() — box-filters cover art down to a fixed 128×192 CT16 tile on the EE

Why the cover rescaler is a hard prerequisite, not an optimization

OPL uploads covers at the PNG's native resolution, capped only by maxSize = 720*512*4 = 1,440 KiB per texture (textures.c). That is most of the ~1,856 KiB TexManager pool spent on one cover. It works today because the menu only ever shows one at a time and the pool streams.

A shelf of seven wants 3–10 MiB. That does not fit in the console. So shelf covers are box-filtered to a 128×192 CT16 tile (48 KiB) at load time, cached, and the native image is never allocated as a texture at all — it cannot reach VRAM even transiently.

The filter runs over libpng's decoded RGBA rows rather than over a GSTEXTURE, which sidesteps the GS-specific packing entirely (T8 stores a swizzled CLUT, T4 swaps its nibbles) and keeps one code path for CT32, CT24, grayscale and palette.

Cost, measured in PCSX2 on a 1024×512 palettized PNG (worse than any real cover): PNG decode 152 ms, box filter 37 ms. It runs on the IO thread (ioPutRequest), not the render thread, so it drops no frames — and it's a +24% on a decode cost OPL already pays.

Measurements

VRAM — measured in PCSX2. This one is reliable: it's address accounting, not performance.

Framebuffers (NTSC 640×448 CT24)	2,240 KiB
Blur chain	224 KiB
TexManager pool remaining	1,632 KiB

The chain costs 224 KiB, not the 210 first estimated: gsKit_texture_size() aligns to pages, so the RT heights round up. It comes out the same in PAL, because those heights land on the same aligned boundaries.

Fill rate — calculated. Pixels written per frame don't depend on anything an emulator fakes.

The blur chain writes 320·224 + 128·112 + 4·(128·112) = 143,360 px = half a screen.

Assumed fill rate	Blur chain	Whole PS5 theme
1.18 Gpx/s (textured, theoretical peak)	0.7% of frame	9%
0.50 Gpx/s (pessimistic, eDRAM-bound)	1.7% of frame	21%

⚠️ Testing status — please read

Verified in PCSX2. NOT verified on real hardware. I no longer have a physical PS2, which is why this is a draft.

PCSX2 is fine for VRAM accounting and for confirming that pixels land where they should. It is useless for frame rate: it models neither GS fill cost nor TexManager pressure.

Three questions I cannot answer, and would be grateful for help with:

1. Frame rate on real hardware, NTSC and PAL. Note the risk is not the blur — the blur is ~1.7% of a frame. It's the theme's composition, which stacks roughly 6.1 screens of fill per frame.
2. TexManager thrashing. The working set (~1 MiB) fits the shrunken pool (1,632 KiB) on paper, but per-frame DMA re-uploads show up as lost fps, not as a visual glitch.
3. FAT vs SLIM, and PAL — where the pool is tighter (1,312 KiB).

Build with make DEBUG=1: the debug overlay shows fps, KiB FIXED / KiB TEXMAN, and the cover rescaler's timings — exactly what's needed to answer the above.

To try the theme: copy themes/PS5/ to <device>/THM/PS5/ and select it in Settings → Interface. It is not the default.

Degradation

• 720p / 1080i — blur disabled, no VRAM reserved, panels fall back to a solid tint
• No VRAM — same
• No blur at all — CoverWallpaper draws the cover sharp, and the gradient veil still guarantees text contrast

The UI stays usable in every case.