Orgnaization & cleanup

This commit is contained in:
Zachary Levy
2026-04-30 16:52:55 -07:00
parent 16989cbb71
commit fd64bc01bf
13 changed files with 269 additions and 258 deletions
+9 -12
View File
@@ -2,9 +2,9 @@
// Backdrop downsample fragment shader.
// Reads source_texture (full-resolution snapshot of pre-bracket framebuffer contents) and
// writes a downsampled copy at factor 1, 2, 4, 8, or 16. The output is the working texture
// (sized at full swapchain resolution); larger factors only fill a sub-rect of it via the
// CPU-set viewport. See backdrop.odin for the factor selection table (Flutter-style).
// writes a downsampled copy at factor 1, 2, or 4. The output is the working texture (sized
// at full swapchain resolution); larger factors only fill a sub-rect of it via the CPU-set
// viewport. See backdrop.odin for the factor selection table (Flutter-style).
//
// Shader paths by factor:
//
@@ -15,15 +15,12 @@
// factor=2: each output covers a 2×2 source block. Single bilinear tap at the shared
// corner reads all 4 source pixels with 0.25 weight.
//
// factor>=4: each output covers a (factor)×(factor) source block. We use 4 bilinear taps,
// each at the shared corner of a (factor/2)×(factor/2) sub-block. Each tap reads
// 4 source pixels uniformly; combined, the 4 taps sample 16 source pixels arranged
// uniformly across the block. This is an approximation of a true (factor)² box
// filter — exact at factor=4 (16 pixels = full coverage), undersampled at factor=8
// (16 pixels of 64) and factor=16 (16 of 256). Flutter uses a richer 13-tap COD-
// style downsample shader at high factors; we accept the simpler 4-tap pattern
// for now since the high-factor cases come with large kernels that mask any
// residual aliasing.
// factor=4: each output covers a 4×4 source block. We use 4 bilinear taps, each at the
// shared corner of a 2×2 sub-block. Each tap reads 4 source pixels uniformly;
// combined, the 4 taps sample 16 source pixels arranged uniformly across the
// block (full coverage at factor=4). The factor>=4 path is structured so the
// same shader code would extend to factor=8 (16 pixels of 64) or factor=16 (16
// of 256) if the CPU-side cap is ever raised, though the current cap is 4.
//
// The viewport+scissor are set by the CPU to limit output to the layer's work region in
// working-texture coords (work_region_phys / factor), clamped to the texture bounds.