[Bug]: Theme preview shows the raw framebuffer, with none of the CRT effects the theme would apply

[relmer]

What happened?

The preview on Settings -> Theme draws the emulated picture with no CRT processing at
all. Scanlines, bloom, color bleed, persistence and gamma are all absent, so the preview
cannot show the one thing that most distinguishes the three themes from each other.

Both preview paths take raw framebuffer bytes:

• Flat themes (Dark Modern, Retro Terminal): ThemePage::PaintPreviewWindow in
  Casso/Ui/Settings/ThemePage.cpp blits framebufferSource with the 2D painter.
• Skeuomorphic: SettingsSheet calls m_previewScene.UploadPicture (fbPixels, ...)
  and renders PictureSrv() onto the glass. Its own comment says the picture comes from
  the emulator's framebuffer bytes.

Neither goes through CrtPostProcess::Process.

I expected the preview to show the picture as that theme would actually render it.

It should preview the theme's own settings, not the live ones

The preview should resolve the CRT parameters for the theme being previewed, through
the same layering MakeCrtParams uses but seeded with that theme's crtDefaults. What
is on screen right now is not the answer: picking Retro Terminal in the list should show
Retro Terminal's heavy scanlines and bloom even while Dark Modern is still the active
theme.

There is a wrinkle worth deciding rather than tripping over. When a monitor's
userOverride is true, the resolver ignores theme defaults entirely, so choosing a
different theme changes nothing about the CRT look. An accurate preview would then show
the same picture for all three themes, and showing each theme's defaults would be
promising something selecting it will not deliver. The preview has to pick one of those
and be consistent about it.

Steps to reproduce

1. Boot Apple2/Demos/casso-rocks.dsk, answer M so the dithered image draws.
2. Settings -> Theme.
3. Compare the preview against the real picture behind the sheet. The preview has no
   scanlines and no bloom.
4. Move through the themes. The chrome changes; the picture's CRT look never does.

Related

Same root cause as #132: the CRT chain runs on the GPU inside CrtPostProcess, and
every consumer that reads the framebuffer directly misses it. A fix for one may well
supply the mechanism for the other.

Emulated machine

Apple //e

Casso version

v1.22.0 x64 (2026-09-02)

Windows version

Windows 11 Pro 10.0.26200