Hello there!

I have found a few other issues related to sRGB, but they simply do not help me and I am still incredibly confused. My problem is that ContextBuilder::with_srgb does not seem to have any effect. Check out this minimal example (using glium):

#[macro_use]
extern crate glium;

fn main() {
    #[allow(unused_imports)]
    use glium::{glutin, Surface};

    let events_loop = glutin::EventsLoop::new();
    let wb = glutin::WindowBuilder::new();
    let cb = glutin::ContextBuilder::new().with_srgb(false); // MARK A -------
    let display = glium::Display::new(wb, cb, &events_loop).unwrap();

    #[derive(Copy, Clone)]
    struct Vertex {
        position: [f32; 2],
    }

    implement_vertex!(Vertex, position);

    let shape = vec![
        Vertex { position: [-1.0, -1.0] },
        Vertex { position: [-1.0,  1.0] },
        Vertex { position: [ 1.0, -1.0] },
        Vertex { position: [ 1.0,  1.0] },
    ];

    let vertex_buffer = glium::VertexBuffer::new(&display, &shape).unwrap();
    let indices = glium::index::NoIndices(glium::index::PrimitiveType::TriangleStrip);

    let vertex_shader_src = r#"
        #version 140
        in vec2 position;
        void main() {
            gl_Position = vec4(position, 0.0, 1.0);
        }
    "#;

    let fragment_shader_src = r#"
        #version 140
        out vec4 color;
        void main() {
            color = vec4(vec3(0.5), 1.0);
        }
    "#;

    let program = glium::Program::new(
        &display,
        glium::program::ProgramCreationInput::SourceCode {
            vertex_shader: vertex_shader_src,
            tessellation_control_shader: None,
            tessellation_evaluation_shader: None,
            geometry_shader: None,
            fragment_shader: fragment_shader_src,
            transform_feedback_varyings: None,
            outputs_srgb: false,  // MARK B ----------------------------------
            uses_point_size: false,
        }
    ).unwrap();

    loop {
        let mut target = display.draw();

        target.draw(&vertex_buffer, &indices, &program, &uniform!{}, &Default::default()).unwrap();
        target.finish().unwrap();
    }
}

There are two places of interest which I will explain later.

• .with_srgb(_) // MARK A
• outputs_srgb: _, // MARK B

My test setup is the following: I run this program and take a screenshot and then inspect what color value the pixels have. For the four possible configurations, I get the following values:

| | .with_srgb(false) | .with_srgb(true) | | - | - | - | | outputs_srgb: false | #bbbbbb | #bbbbbb | | outputs_srgb: true | #808080 | #808080 |

So as far as I understand: there is the GL_FRAMEBUFFER_SRGB flag. If that flag is false, OpenGL does not perform any conversion from fragment shader to frame buffer. If it is enabled, however, OpenGL assumes that the shader output is linear RGB and will thus -- if the frame buffer has an sRGB format -- convert the shader output to sRGB. In glium, GL_FRAMEBUFFER_SRGB is controlled by the outputs_srgb parameter of the program. If the latter is false, GL_FRAMEBUFFER_SRGB is set to true and the other way around.

Additionally, I would expect glutin to create a framebuffer with the format specified by .with_srgb(_). As such, I have the following expectations:

• ✗ with_srgb(false) and outputs_srgb: false: the framebuffer should be linear RGB, meaning that no conversion should happen, regardless of GL_FRAMEBUFFER_SRGB. As such, I would expect #808080, but I got #bbbbbb.
• ✔ with_srgb(true) and outputs_srgb: false: the framebuffer should be sRGB and since the shader does not output sRGB, I expect OpenGL to convert. As such, I expect #bbbbbb, which I actually got.
• ✔ with_srgb(false) and outputs_srgb: true: as above, the framebuffer should be linear RGB, meaning that no conversion should happen, regardless of GL_FRAMEBUFFER_SRGB. As such, I would expect #808080 which I luckily also got.
• ✔ with_srgb(true) and outputs_srgb: true: the framebuffer is sRGB, but the shader also outputs in that color space, so no conversion should happen. As such I expect #808080 which I got.

This issue is about the first situation. As far as I can tell, this is just wrong.

I tested the above on several platforms: Ubuntu 18.04, MacOS and Windows. I always got the same results (well, on MacOS and Windows the #bbbbbb was slightly off, but still way more than #808080).

(I also did a test with GLFW in case that's interesting. I used the simple example and changed line 63 to " gl_FragColor = vec4(vec3(0.5), 1.0);\n". Running that, I get a #808080 triangle.)

Am I doing something wrong? Am I completely misunderstanding color spaces? Is this a bug in glutin/glium/...? Would be super great if someone could help me!

Ever since the windowing part of glutin was separated into its own crate (winit), much of glutin's API has felt clunky and unnecessary. In particular, the wrapping around winit's Window, WindowBuilder and EventsLoop can be frustrating to maintain, requiring wrapper methods around all methods on each of those types, even if glutin itself doesn't do anything interesting with those methods. This means that any time winit's API is tweaked in the slightest, glutin normally also requires updating.

After giving it some thought, I've been thinking that glutin might benefit from a redesign that removed all Window and EventsLoop related code in favour of a simpler API purely aimed at setting up and using an OpenGL context. This PR is currently a draft of that change, mainly to get some feedback and thoughts from other glutin/glium users.

So far the API and linux backends have been updated, along with the window example to demonstrate what usage might look like.

I haven't looked closesly at how these changes will work with glium yet, so there might still be some more API problems to solve. I'll take a closer look at this soon.

@tomaka a while back you mentioned that glutin could use a redesign. If you get a chance, it would be great to get your thoughts on this and what you originally had in mind.

Mostly backporting winit functions into emscripten's platform module. It compiles and works against a modified version of badboy's glium example: https://github.com/cactorium/spring-crabs/tree/emscripten

As mentioned in #1398/#1411 we should have an example that showcases how to deal with the Android activity lifecycle. Ultimately this turns into a helper function on ContextWrapper that has access to the internal surface for recreation, as did the broken implementation prior to #1411. At the same time I hope to replace new_windowed() with an implementation soon™ that takes a RawWindowHandle, making the code more generic, winit-agnostic, and allows users to use Android Surfaces for specific views in their Java/Kotlin/Flutter apps without needing a fullscreen NativeActivity.

This PR is based on top of #1412 so that my editor doesn't go bonkers on all the lint warnings/errors :)

Signed-off-by: Hal Gentz [email protected]

Does #1028

Currently only 4 platforms need testing and one platform needs to get working.

Compiles with the following backends:

• [x] Linux | X11 | EGL
• [x] Linux | X11 | GLX
• [x] Linux | Wayland | EGL
• [x] Linux | OSMesa
• [x] Windows | WGL
• [x] Windows | EGL
• [x] Web | Emscripten
• [x] macOS
• [x] iOS
• [x] Android

Has been tested with the following backends:

• [x] Linux | X11 | EGL
• [x] Linux | X11 | GLX
• [x] Linux | Wayland | EGL
• [x] Linux | OSMesa
• [x] Windows | WGL
• [x] Windows | EGL
• [ ] Web | Emscripten
• [x] macOS
• [x] iOS
• [x] Android

Adds a way to create opengl contexts from an already existing window.

This might result in suboptimal config for windows on X11, but it should still work.

I currently only plan to implement this functionality on linux and windows. Currently untested.

Implemented:

• [x] Linux - X11 - GLX
• [x] Linux - X11 - EGL
• [x] Linux - Wayland - EGL
• [x] Windows - EGL
• [x] Windows - HWND

Tested:

• [x] Linux - X11 - GLX
• [x] Linux - X11 - EGL
• [x] Linux - Wayland - EGL
• [x] Windows - EGL
• [x] Windows - HWND

Signed-off-by: Hal Gentz [email protected]

• [ ] Tested on all platforms changed
• [x] Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• [x] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• [x] Created an example program if it would help users understand this functionality

Fixes #1089, closes #1091.

This is an attempt at solving issue #839.

So far, I have added a 'constructor' method on glutin::WindowBuilder that takes in a winit::WindowBuilder.

I also have put methods on the Window structs for Windows, MacOS, and Android to convert a Window into a winit::Window. I am unsure how to achieve this on Linux, as the Linux platform code does not appear to keep a winit::Window inside its Window struct.

Another thing that needs to be taken into consideration is that currently the methods to get the winit::Window from the platform Window consume the platform Window. I am unsure if this is the desired behavior or not, as I am not familiar with the exact reasons we did this.

These changes were by no means difficult, but I appreciate being allowed to make them.

Please let me know any points I missed, or anything I should do differently.

Running the window example on Windows 10, with Intel GMA X4500 GPU results in error NoAvailablePixelFormat at .\examples/window.rs:11. Glutin version is 0.9.1. Is it possible to configure the context to support this GPU? Let me know if more information is needed.

Migrated from jwilm/alacritty#1269

A segfault occurs when using glutin with the binary Nvidia driver and a Wayland compositor.

Backtrace obtained from rust-gdb from running glutin's window example:

https://gist.github.com/aidanharris/f1fe409c463e79c575242a9edd255ea8

If I force the mesa driver to be used instead of Nvidia's library (env LD_PRELOAD=/usr/lib64/libEGL.so cargo run --example window) no segfault occurs and the example runs fine (I assume mesa is doing software rendering but it does work so perhaps this is an issue with the Nvidia driver?).

Trying to run on Ubuntu 14.04

kuviman@UbuntuBox:~/Temp/glutin$ cargo run --example window
    Finished dev [unoptimized + debuginfo] target(s) in 0.21s
     Running `target/debug/examples/window`
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
window: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)

I noticed that GLFW now supports Vulkan (http://www.glfw.org/docs/3.2/vulkan.html). I don't know if this is planned or already in progress for glutin so I thought I'd raise an issue for visibility.

• [X] Tested on all platforms changed
• [X] Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• [ ] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• [ ] Created or updated an example program if it would help users understand this functionality

Hello again,

I've looked into implementing these missing methods on CGL/WGL. For the CGL implementation I'm not sure whether the nil check is necessary, if not then the maybe the return type could be changed to u32 since all Platforms have an implementation now?

When trying to run the example it panics because it can't create an ES context (I suppose it tried creating a GL one before). The Device in question is an X220t with an i5-2520M / HD Graphics 3000 running up-to date Windows 10. The same machine can create/run an OpenGL 3.1 context with old glutin just fine, so the hardware/driver should be fine.

$ cargo run --example window
    Blocking waiting for file lock on build directory
   Compiling glutin_examples v0.1.3 (C:\Users\benny\src\glutin\glutin_examples)
    Finished dev [unoptimized + debuginfo] target(s) in 3.16s
     Running `target\debug\examples\window.exe`
Picked a config with 0 samples
thread 'main' panicked at 'failed to create context: Error { raw_code: None, raw_os_message: None, kind: NotSupported("extension to create ES context with wgl is not present") }', glutin_examples\src\lib.rs:74:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\examples\window.exe` (exit code: 101)

Previously I could query this with window_ctx.get_pixel_format().hardware_accelerated. Is there a way to tell this using 0.30?

Use case: Robo Instructus uses this to automatically set various graphics options to low.

I thought I'd experiment with reducing the noise using glutin-winit vs glutin 0.29. This pr adds glutin_winit::GlWindow trait with extensions for winit Windows. (It could alternatively be called glutin_winit::WindowExt if you prefer).

I updated the example replacing the example GlWindow struct as it's simpler to use the trait.

I think this is quite a light touch, but still useful. Wdyt?

• [x] ~Tested on all platforms changed~
• [x] ~Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users~
• [x] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• [x] Created or updated an example program if it would help users understand this functionality

I've used multiple Rust projects with windowing support and managed to track the issue to Glutin. Some other projects I've tried are Neovide, WezTerm and Alacritty. By running the window example on my secondary monitor, I can get the crash as appears in the attached screenshot. Running from my primary window does not give any issue like this. When I try to close it, I get an error about the window not responding. I'm on Windows 11 64 bit. I am not able to view the console window, since I was having trouble getting the window to open on my secondary monitor while it is enabled. I had to add #![windows_subsystem = "windows"] to the window example to get it to open on my secondary monitor.