[Filip722]

Codex Switcher's Linux dashboard can retain substantial GPU memory for Skia tile painting while idle. On the 0.2.20 AppImage with an AMD integrated GPU, selecting CPU tile painting reduced resident VRAM across the app's DRM clients from roughly 273 MiB to 75 MiB while retaining responsive scrolling.

• Default Skia tile painting to the CPU before WebKit starts, preserving explicit WEBKIT_SKIA_ENABLE_CPU_RENDERING overrides.
• Keep WebKit's GPU compositing and asynchronous scrolling available.
• Extend the existing Linux startup regression tests to verify the painting default and ensure compositing and DMA-BUF rendering are not disabled.
• Document the GPU-painting override, version-dependent savings, and an optional Mesa software-OpenGL mode for further GPU-memory reduction.

A matched four-second scrolling sequence used 0.25 CPU-seconds with CPU tile painting, compared with 0.51 in the original GPU-painting baseline on this machine. These measurements describe the AppImage's bundled WebKit; they are not a guarantee of the same savings on other WebKit versions.

An optional Mesa software-OpenGL launch mode also tested with no direct DRM GPU allocations in the app processes, while retaining scrolling the user found acceptable. It used 2.24 CPU-seconds for the same scrolling sequence and roughly 40 MiB more summed process RSS than the CPU-painting/GPU-compositing baseline. It remains opt-in because it trades GPU memory for CPU work and RAM, is driver-dependent, and applies to graphical child processes as well. Desktop-compositor allocations are outside these per-app measurements.