8-bit quantization when rendering F32 colours into RGBA16F surface

[Marc Pabst]

Hi all, 

On iOS/Metal I wrap an RGBA16F MTLTexture into an SkSurface (ColorType::RGBAF16). Drawing solid colors (no images, no saveLayer) with BlendMode::Src and alpha 1.0 still lands on ~1/255 steps when inspecting in Xcode capture (not FP16’s ~1/1024).

Questions:
- Is there a known path on Metal where Ganesh packs solid colors to UNORM8 or renders via an RGBA8888 intermediate when using a wrapped render target?
- How can I force a fully float path for solids on Metal?

Thanks!

[Michael Ludwig]

Yes, in Ganesh, certain geometry renderers will use colors packed into UNORM8x4 vertex attributes to allow for disparate Skia draw calls to be batched into a smaller number of GPU draws. This decision is based on whether or not the color value returns true from `SkColor4f::fitsInBytes()` which is true when all channels fall in the range [0, 1].  This logic is intended to detect when color values were meant to carry wide gamut values that must store things outside of [0,1] to correctly represent the value in the current color space.  Unfortunately, the logic does not take into account whether or not the precision of the output surface would show that quantization.

In Graphite, colors are always kept in at least F16 until they are rendered, so this inconsistency should not arise.

[Marc Pabst]

Thanks, that's helpful! Aktough that seems like quite a big footgun....

I'm unfortunately using Skua through the skia-safe Rust bindings, so I currenlty can't just switch to Graphite. Is there any workaround using Ganesh?

[Marc Pabst]

Hi, thanks - I can confirm that always just returning "false" for `fitsInBytes()` fixes this issue for me! Is there any chance this could be exposed as a compile time option?

On Thursday, 25 September 2025 at 20:41:00 UTC+1 michae...@google.com wrote: