hadronized / luminance-rs

Type-safe, type-level and stateless Rust graphics framework
https://phaazon.github.io/learn-luminance/
Other
1.09k stars 59 forks source link

`PipelineState::srgb_enabled` is ignored by WebGL2 backend #561

Open kpreid opened 2 years ago

kpreid commented 2 years ago

enable_srgb(true) has no effect on rendering when using the WebGL2 backend. It has the expected effect when using the gl33 backend.

A quick text search suggests that the problem is lack of corresponding code to enable/disable the FRAMEBUFFER_SRGB state in luminance-webgl.

hadronized commented 2 years ago

Yeah, this is an extension normally. I’m not sure how to do that correctly in the WebGL backend.

kpreid commented 2 years ago

Gah. I had sloppily assumed that this situation had improved in the years since I initially noticed that WebGL said nothing about color spaces…

It would be nice if luminance could communicate “not supported; manage it yourself”. (Though doing that naively in the compile-time style would require parameterizing PipelineState with the Backend.)

kpreid commented 2 years ago

In case anyone else has the same momentary confusion I did: I heard that EXT_sRGB was moved to core in WebGL 2, but as far as I can tell, this only lets you ask for sRGB encoded storage in renderbuffers, which are for offscreen rendering and don't affect the canvas.

(Also, the whole idea of asking for sRGB is only an approximation to the ideal result, which would be asking for conversion from linear to whatever color space the browser thinks is best — since browsers are already aware of monitor color profiles for rendering images and this could produce better results than an intermediate sRGB step. But, there doesn't seem to be any motion towards having a standard for that, and it seems like the general expectation is that canvas pixels are sRGB in either type of canvas.)