PistonDevelopers
"Pixel format not found" due to default sRGB-enabled context is still an issue
piston_window ver. 0.44 on ubuntu 14.04 (and probably on older systems)
The issue with default srgb(true) in the PistonWindow impl of BuildFromWindowSettings is still there: using old OSes with drivers not supporting srgb result in "pixel format not found" error when running sample applications.
Luckily, there is a simple dirty hackaround (without specifying pistoncore-glutin_window as an additional crate dependency): it's possible to break encapsulation with the help of the type inferencing mechanism
let mut wnd: PistonWindow = PistonWindow::new(OpenGL::V2_1, 0,
WindowSettings::new("Hello", (800,600))
.opengl(OpenGL::V2_1)
.srgb(false)
.build() // hack around default srgb(true) (builds GlutinWindow instead of PistonWindow)
.unwrap());
But is it really necessary to enforce .srgb(true) in such a strict way? (I.e. is the sRGB support absolutely necessary for the gfx library to work without random crashes or the worst thing which could happen is only a slight nonintercoherence of image colors?)
I opened https://github.com/PistonDevelopers/gfx_graphics/issues/293.
Gfx uses different types for linear (Rgba8) and sRGB color space (Srgba8). Since gfx_graphics currently uses Srgba8, the WindowSettings::srgb is overriden to true to turn on the feature in the window backend.
Notice that with sRGB disabled, Rgba8 behaves like Srgba8 but the gamma correction is non-linear in the shader pipeline. sRGB is actually a feature to fix a legacy issue where image editors and cameras used a gamma 2.2 non-linear color space to get linear gamma response on CRT screens. Unfortunately the internet was invented before LCD technology was widely used, so changing the image formats was too much work, so now LCD screens are manufactured to respond to gamma 2.2 while new graphics card has special circuitry to do the conversion. This is why old graphics cards does not support sRGB.
sRGB is similar to gamma 2.2 but with nicer analytic properties. Technically, most image formats should be treated as sRGB.
See https://github.com/PistonDevelopers/piston/issues/1014 for more information.
Ok, I see GL_ARB_framebuffer_sRGB, so it's not simply the lack of srgb support.
@kvark Yes, there is GL_ARB_framebuffer_sRGB in my glxinfo output, but in a wrong section. glutin queries the extension info by means of
let extensions = glx.QueryExtensionsString(display as *mut _, screen_id);
Then the function choose_fbconfig returns an Err() when srgb is required but GLX_ARB_framebuffer_sRGB or GLX_EXT_framebuffer_sRGB aren't in the list returned by glxQueryExtensionsString.
I have experimented with glxQueryExtensionsString and found that it returns the list which goes in the glxinfo output in the section named "GLX extensions". But in my case one of those extensions is only in the "client glx extensions" section, which can be queried by means of glXGetClientString with the second parameter GLX_EXTENSIONS.
Wow, great investigation, @arbrk1!
So, if I understand correctly, Glutin needs to take the client extensions into account under some conditions (e.g for the compatibility context)?
Cc @tomaka
On Apr 25, 2016, at 18:31, arbrk1 [email protected] wrote:
@kvark Yes, there is GL_ARB_framebuffer_sRGB in my glxinfo output, but in a wrong section. glutin queries the extension info by means of
let extensions = glx.QueryExtensionsString(display as *mut _, screen_id); Then the function choose_fbconfig returns an Err() when srgb is required but GLX_ARB_framebuffer_sRGB or GLX_EXT_framebuffer_sRGB aren't in the list returned by glxQueryExtensionsString.
I have experimented with glxQueryExtensionsString and found that it returns the list which goes in the glxinfo output in the section named "GLX extensions". But in my case one of those extensions is only in the "client glx extensions" section, which can be queried by means of glXGetClientString with the second parameter GLX_EXTENSIONS.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub
@arbrk1 Can you test with the sdl2_window backend by changing to PistonWindow<Sdl2Window> to see if you get a similar error?
@bvssvni sdl2_window backend works perfectly for my configuration. As I understand (looking at src/video/x11/SDL_x11opengl.c from SDL2) SDL2 passes a requirement for an SRGB-compatible context directly to glXChooseFBConfig while glutin introduces an additional layer of extension-availability checks before calling glXChooseFBConfig.
Unrelated issue (click to expand)
This occurs for me even with the hack of creating PistonWindow manually. I've been told that this error is because of sRGB so I'm posting it here, but if it is an unrelated error I can make a new issue. This occurs in piston 0.22 & piston_window 0.47, but not piston 0.19 & piston_window 0.42.$ RUST_BACKTRACE=1 cargo run
Running `target/debug/bw-adventures`
Successfully created first window
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: DescriptorInit(PixelExport(255, None))', ../src/libcore/result.rs:746
stack backtrace:
1: 0x55c0a0dfffd0 - sys::backtrace::tracing::imp::write::h3675b4f0ca767761Xcv
2: 0x55c0a0e028bb - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.44519
3: 0x55c0a0e02528 - panicking::default_handler::h18faf4fbd296d909lSz
4: 0x55c0a0df682c - sys_common::unwind::begin_unwind_inner::hfb5d07d6e405c6bbg1t
5: 0x55c0a0df6cb8 - sys_common::unwind::begin_unwind_fmt::h8b491a76ae84af35m0t
6: 0x55c0a0dff441 - rust_begin_unwind
7: 0x55c0a0e31d3f - panicking::panic_fmt::h98b8cbb286f5298alcM
8: 0x55c0a0ac09b4 - result::unwrap_failed::h6985425857571444624
at ../src/libcore/macros.rs:29
9: 0x55c0a0ac0739 - result::Result<T, E>::unwrap::h17750157649990784447
at ../src/libcore/result.rs:687
10: 0x55c0a0ac05c6 - gfx_graphics::back_end::Gfx2d<R>::new::_$u7b$$u7b$closure$u7d$$u7d$::closure.25451
at /home/daboross/.cargo/registry/src/github.com-88ac128001ac3a9a/piston2d-gfx_graphics-0.28.0/src/back_end.rs:215
11: 0x55c0a0ac10b7 - back_end::PsoStencil<T>::new::h12884116355933234546
at /home/daboross/.cargo/registry/src/github.com-88ac128001ac3a9a/piston2d-gfx_graphics-0.28.0/src/back_end.rs:123
12: 0x55c0a0aaf67f - back_end::Gfx2d<R>::new::h656842580009299534
at /home/daboross/.cargo/registry/src/github.com-88ac128001ac3a9a/piston2d-gfx_graphics-0.28.0/src/back_end.rs:230
13: 0x55c0a0a974cf - PistonWindow<W>::new::h7085292114642368369
at /home/daboross/.cargo/registry/src/github.com-88ac128001ac3a9a/piston_window-0.47.0/src/lib.rs:191
14: 0x55c0a0a93ab2 - run::h4275c3a05e788418njd
at src/rust/lib.rs:45
15: 0x55c0a0a93788 - main::hbb8d27b139002075faa
at src/bin/bw-adventures.rs:4
16: 0x55c0a0e02184 - sys_common::unwind::try::try_fn::h14622312129452522850
17: 0x55c0a0dff3cb - __rust_try
18: 0x55c0a0e01c1b - rt::lang_start::h0ba42f7a8c46a626rKz
19: 0x55c0a0a937c9 - main
20: 0x7f994390661f - __libc_start_main
21: 0x55c0a0a93678 - _start
22: 0x0 - <unknown>
Process didn't exit successfully: `target/debug/bw-adventures` (exit code: 101)
Code:
let opengl_version = opengl_graphics::OpenGL::V3_0;
let mut window = {
let settings = WindowSettings::new("b-w-adventures", [640u32, 480u32])
.exit_on_esc(false)
.srgb(false)
.opengl(opengl_version);
let samples = settings.get_samples();
let window = settings.build().unwrap();
println!("Successfully created first window");
PistonWindow::new(opengl_version, samples, window)
// window
};
glxinfo: http://sprunge.us/BjaU
@daboross that's not sRGB. That happens when your PSO definition is lacking the output target component. Since the definition comes from gfx_graphics, it surely has a bug in there then.
ok, I briefly looked at gfx_graphics and didn't see anything wrong in there.
the bug might be related to https://github.com/gfx-rs/gfx/pull/927 , especially considering the weird slot 255 in the error. cc @csherratt
@kvark Ok, awesome - I'll open an issue there.
Edit: Opened https://github.com/gfx-rs/gfx/issues/977