Feature request: setViewClear should support specifying the color as floats, not just u8

[jwdevel]

When using a SRGB back buffer (BGFX_RESET_SRGB_BACKBUFFER), that means the clear color is specified in linear light, and converted to sRGB when written into the back buffer.

As a result, the precision available for representing dark clear colors is rather poor.

This is one of the reasons people use the sRGB encoding in the first place — better mapping to human perception, especially in near-black colors. When we specify linear light using a u8 (as bgfx forces us to, when using the above settings), we throw away useful precision.

In the underlying backends, float is used, as is proper. For instance, in GL it calls glClearColor(float, float, float, float).
But there is no way to pass a float directly through bgfx, that I have found.

I imagine this would simply be a new setViewClear override, and the internal bgfx::Clear struct would need to store floats, as well.

[pezcode]

Have you tried the overload that takes a palette index?

setPaletteColor() lets you set float RGBA values so this might work.

[jwdevel]

I saw that, but wasn't sure what it's about. I'm not using palettized colors in general.

But I guess this notion of palette is an internal bgfx mapping, and not at all related to a "framebuffer palette" (as in a framebuffer that uses palettized colors; pretty uncommon these days)?

Looking now, I see in the code that the bgfx palette is used for texture border color sampler params, so figured that was something different.

Eg, here:

bgfx/src/renderer_gl.cpp

Line 7664 in 2a97915

texture.commit(ii, bind.m_samplerFlags, _render->m_colorPalette);

But then I do also see it being used for clear color, as you mention, here:

bgfx/src/renderer_gl.cpp

Line 4503 in 2a97915

const float* rgba = _palette[index];

Is that same palette used for both purposes? That seems odd to me, but maybe I misunderstand...

[pezcode]

The bgfx "palette" is just a set of 256 full-rage colors you can set and then reference by index for border color and per-attachment clear values. If I had to speculate I'd say for these two cases it simplifies pipeline state caching and avoids dragging 8*4 float color values for each view?

But yes, this has nothing to do with the concept of a palettized framebuffer. It's a bgfx-internal concept of a color "cache".

[bkaradzic]

and avoids dragging 8*4 float color values for each view?

Yes, the point is that you're usually dealing with few floating-point colors for the whole duration of your application. There is no point of submitting it everywhere when it can be just cached.

[jwdevel]

cool; thanks for the help. I guess I can get it done this way (: