egui uses the sRGB color space, but when using the sRGB color space, the default framebuffer color space must be sRGB, but there is no way to reliably specify the default framebuffer color space.
In summary,
we need a reliable way to specify the default framebuffer color space, and we don't have it.
Hi,
EXT_sRGB only converts linear space and sRGB space to each other when writing to the color attachment and during blending operations, but the default framebuffer color space is implementation-dependent. Also, EXT_sRGB_write_control only specifies whether to enable or disable the conversion when EXT_sRGB is available, and does not know about the default framebuffer format. Therefore, it is necessary to either not use sRGB or add an api to specify the color space explicitly to this crate. However, if you want to add api, you need to know the color space of the default frame buffer.
GLES does not standardize EXT_sRGB_write_control, so it cannot be used in basicaly.
{GLX,WGL}_FRAMEBUFFER_SRGB_CAPABLE_ARB has no effect in some environments(OpenGL api is good, GLES api is bad, etc toooooooo!).
Implementation too buggy.
EGL 1.5 can use KHR_gl_colorspace.
Fundamentally, it is the spec issue. Since WebGL is also based on GLES, there is no similar function for {GLX,WGL}_FRAMEBUFFER_SRGB_CAPABLE_ARB, so there is nothing we can do. If we're lucky, we can create a surface with an sRGB default framebuffer with {GLX,WGL}_FRAMEBUFFER_SRGB_CAPABLE_ARB or KHR_gl_colorspace. But, sRGB is confused.
I DELETED something important while editing.
egui uses the sRGB color space, but when using the sRGB color space, the default framebuffer color space must be sRGB, but there is no way to reliably specify the default framebuffer color space.
In summary,we need a reliable way to specify the default framebuffer color space, and we don't have it.Hi,
EXT_sRGB
only converts linear space and sRGB space to each other when writing to the color attachment and during blending operations, but the default framebuffer color space is implementation-dependent. Also,EXT_sRGB_write_control
only specifies whether to enable or disable the conversion whenEXT_sRGB
is available, and does not know about the default framebuffer format. Therefore, it is necessary to either not use sRGB or add an api to specify the color space explicitly to this crate. However, if you want to add api, you need to know the color space of the default frame buffer.GLES does not standardize
EXT_sRGB_write_control
, so it cannot be used in basicaly.{GLX,WGL}_FRAMEBUFFER_SRGB_CAPABLE_ARB
has no effect in some environments(OpenGL api is good, GLES api is bad, etc toooooooo!).Implementation too buggy.
EGL 1.5 can use
KHR_gl_colorspace
.Fundamentally, it is the spec issue. Since WebGL is also based on GLES, there is no similar function for
{GLX,WGL}_FRAMEBUFFER_SRGB_CAPABLE_ARB
, so there is nothing we can do. If we're lucky, we can create a surface with an sRGB default framebuffer with{GLX,WGL}_FRAMEBUFFER_SRGB_CAPABLE_ARB
orKHR_gl_colorspace
. But, sRGB is confused.Thank you.
See Also
Additionally
I tried to provide the minimum source code to reproduce it, but I couldn't find anything solid.
It is possible to reproduce the problem in an environment that meets the following: