A low-level library for OpenGL context creation, written in pure Rust.

Overview

glutin - OpenGL, UTilities and INput

A low-level library for OpenGL context creation, written in pure Rust.

Docs.rs

[dependencies]
glutin = "0.28.0"

Documentation

Contact Us

Join us in any of these:

Matrix Libera.Chat

Usage Examples

Warning: these are examples for master. For the latest released version

Try it!

git clone https://github.com/rust-windowing/glutin
cd glutin
cargo run --example window

Common issues

Please refer to ISSUES.md.

Usage

Glutin is an OpenGL context creation library and doesn't directly provide OpenGL bindings for you.

For examples, please look here.

Note that glutin aims at being a low-level brick in your rendering infrastructure. You are encouraged to write another layer of abstraction between glutin and your application.

Glutin is only officially supported on the latest stable version of the Rust compiler.

Platform-specific notes

Android

To compile the examples for android, you have to use the cargo apk utility.

See the android-rs-glue repository for instructions.

Emscripten with asmjs

Emscripten support has been deprecated in favor of platforms like stdweb. To get an OpenGL context on these platforms, please use crates like glow instead.

X11

The plan is that glutin tries to dynamically link-to and use Wayland w/EGL if possible. If it doesn't work, it will try Xlib w/GLX follow by Xlib w/EGL instead. This is work-in-progress.

Wayland

Due to an issue with how Mesa and Wayland play together, all shared contexts must use the same events pool as each other.

Comments
  • [Windows] Unable to create non-SRGB framebuffer

    [Windows] Unable to create non-SRGB framebuffer

    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!

    opened by LukasKalbertodt 35
  • Redesign - Remove winit `Window` and `EventsLoop` wrappers. Add `Context` type.

    Redesign - Remove winit `Window` and `EventsLoop` wrappers. Add `Context` type.

    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.

    opened by mitchmindtree 30
  • Improve Emscripten support

    Improve Emscripten support

    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

    opened by cactorium 29
  • Add Android example

    Add Android example

    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 :)

    opened by MarijnS95 27
  • Merges context creation code.

    Merges context creation code.

    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
    opened by goddessfreya 26
  • Gentz' Misc Changes

    Gentz' Misc Changes

    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.

    opened by goddessfreya 24
  • Integrate with `winit'

    Integrate with `winit'

    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.

    opened by Plasticcaz 24
  • NoAvailablePixelFormat error

    NoAvailablePixelFormat error

    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.

    opened by gheoan 23
  • Proprietary Nvidia (Wayland): eglCreateWindowSurface failed

    Proprietary Nvidia (Wayland): eglCreateWindowSurface failed

    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?).

    opened by aidanharris 22
  • Assertion `!xcb_xlib_threads_sequence_lost' failed

    Assertion `!xcb_xlib_threads_sequence_lost' failed

    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)
    
    opened by kuviman 22
  • Vulkan support

    Vulkan support

    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.

    opened by bitshifter 22
  • Added `Surface::{width,height}` implementations for CGL/WGL

    Added `Surface::{width,height}` implementations for CGL/WGL

    • [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?

    opened by Melchizedek6809 0
  • Can't create context on old Win 10 Laptop

    Can't create context on old Win 10 Laptop

    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)
    
    opened by Melchizedek6809 0
  • How to tell if the gl-context is hardware accelerated in `0.30`

    How to tell if the gl-context is hardware accelerated in `0.30`

    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.

    opened by alexheretic 0
  • Add glutin-winit GlWindow trait helper

    Add glutin-winit GlWindow trait helper

    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
    opened by alexheretic 2
  • Opening a glutin window on a monitor other than primary monitor for Windows crashes

    Opening a glutin window on a monitor other than primary monitor for Windows crashes

    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.

    example window crash

    opened by ReallySnazzy 9
Releases(v0.30.3)
  • v0.30.3(Dec 8, 2022)

    • Fixed wrong amount of rects committed in Surface::swap_buffers_with_damage with EGL.
    • Added missing Eq, PartialEq, and Hash impls for surface::Rect.
    Source code(tar.gz)
    Source code(zip)
  • v0.30.2(Nov 26, 2022)

    • Fixed robust context creation with EGL.
    • Moved to stable version of wayland-sys.
    • Allow offline renderers with CGL.
    • Fixed an error when compiling the EGL backend with only one of Wayland and X11 enabled.
    Source code(tar.gz)
    Source code(zip)
  • v0.30.1(Nov 12, 2022)

    • Added new glutin-winit crate to help bootstrapping new glutin with winit.
    • Added EGLDevice wrappers for EGL.
    • Added EGL dependent api to make a context current without a surface.
    • Added supports_transparency on GlConfig.
    • On GLX, try all extensions when setting vsync.
    • On WGL, fixed that Surface::swap_buffers takes longer with every call caused by frequent calls of the win32 function HDC GetDC(HWND hWnd).
    Source code(tar.gz)
    Source code(zip)
  • v0.30.0(Oct 26, 2022)

    The glutin was rewritten from the ground to solve its previous design pitfalls. If this rewrite is a surprise to you, it was on the radar for a long time before @kchibisov started seriously maintaining this crate. Previously there was an attempt to do so by @goddessfreya in https://github.com/rust-windowing/glutin/tree/v0.23_reworks , but unfortunately she disappeared and we can only hope that she is alright. While her code wasn't complete the comments about some edge cases were very helpful and saved a lot of time.

    To outline some major issues glutin had and that were solved:

    • The maintenance was hard, since the code was a bag of glue around winit and GL shenanigans.
    • Very hard to use with anything other than winit.
    • MT safety was wrong and it was causing issues on Wayland(EGL in general), since some stuff ended up Send + Sync while it shouldn't due to other platfroms.
    • Impossible for specialized use, like EGL only features.
    • Configuration picking is a mess due to building everything at once(Display, Config, Surface, and Context) leading to complex fallback behavior downsteam.
    • etc.

    The glutin 0.30.0 is more low-level now and its core concepts are now around Display, Config, Context, and Surface, using raw window handle for window related config creation and display creation. Each platform EGL, GLX, WGL, and CGL could be used on their own and every backend/platform are optional.

    For an example of bootstrapping and working with the new glutin we strongly advise to look at the example.

    Unfortunately, not every platform was ported to glutin 0.30.0. The ios, surfaceless, and os-mesa platforms were removed due to the lack of maintenance, however if there's a desire and maintainer for such platforms we'd warmly welcome them and guide through the code.

    More formal changelog:

    • This version of glutin has been rewritten from the ground and no longer depends on winit, the raw-window-handle is now used instead of it.
    • The Api is now built around Display, Surface, Config, and Surface. For more info see crate documentation and examples.
    • Breaking: Bump MSRV from 1.57 to 1.60.
    • The ios support was removed for the lack of maintainance for now. In case there's a need for it, contributions are welcome.
    • The context creation is no longer limited to winit's supported platforms.
    • The underlying Api providers are publically exposed now, so glutin could be used with just e.g. EGL.
    • Fixed soundness issues with Surface MT safety, since before EGLSurface could be sent to a different thread, which is not safe.
    • Fallback to Surface::swap_buffers when Surface::swap_buffers_with_damage is not supported on EGL.
    • iOS, os-mesa, and surfaceless platforms were removed.
    Source code(tar.gz)
    Source code(zip)
  • v0.30.0-beta.3(Oct 23, 2022)

    • Config doesn't force OpenGL Api by default.
    • Display::create_context now uses the most recent available Api from the Config when ContextApi is not specified in ContextAttributes.
    • Breaking: PossiblyCurrentGlContext::get_proc_address method was moved to GlDisplay::get_proc_address.
    • Breaking: ConfigTemplateBuilder::with_sample_buffers now called ConfigTemplateBuilder::with_multisampling.
    • Breaking: GlConfig::sample_buffers now called GlConfig::num_samples and returns the amount of samples in multisample buffer.
    • Breaking: Bump MSRV from 1.57 to 1.60.
    • Fix GlProfile::Core requesting without explicit version.
    • Pick the latest available profile on macOS.
    • When using ContextApi::Gles(None) in ContextAttributesBuilder the latest known supported major ES version will be picked.
    • Fix Eq implementation for Config on CGL.
    • Add GetDisplayExtensions trait to obtain api display extensions implemented on EGL, WGL, and GLX.
    • Fallback to Surface::swap_buffers when Surface::swap_buffers_with_damage is not supported on EGL.
    • Add missing GetGlConfig implementation for NotCurrentContext and PossiblyCurrentContext.
    • Implement Clone for builders.
    • Breaking: move DamageRect into surface::Rect.
    • Add GlDisplay::version_string to help with logging the display information.
    • Rename NotCurrentGlContext::treat_as_current to NotCurrentGlContext::treat_as_possibly_current.
    • Rename Display::from_raw to Display::new.
    • Added GlDisplay::supported_features to allow checking for extensions support beforehand.
    • Breaking: renamed ReleaseBehaviour to ReleaseBehavior.
    • Fix GLX not working with nvidia binary drivers.
    • Fix crash in glx::surface::Surface::set_swap_interval.
    Source code(tar.gz)
    Source code(zip)
  • v0.30.0-beta.2(Sep 3, 2022)

  • v0.30.0-beta.1(Sep 3, 2022)

    • Replace winit dependency with raw-window-handle.
    • The Api is now built around Display, Surface, Config, and Surface for more info see crate documentation and examples.
    • The ios support was removed for the lack of maintainance for now. In case there's a need for it, contributions are welcome.
    • The context creation is no longer limited to winit's supported platforms.
    • The underlying Api providers are publically exposed now, so glutin could be used with just e.g. EGL.
    • Fixed soundness issues with Surface MT safety, since before EGLSurface could be sent to a different thread, which is not safe.
    Source code(tar.gz)
    Source code(zip)
  • v0.29.1(Aug 10, 2022)

  • v0.29.0(Jul 30, 2022)

    • Fix crash when creating OpenGLES context without explicit version.
    • Add buffer_age method on WindowedContext.
    • Return an Err instead of panicking when surfaceless GLX context creation fails on Linux.
    • Fix compilation on Android:
      • Switch from StaticStructGenerator to StructGenerator to dynamically load symbols.
      • Replace android_glue dependency with raw-window-handle, and remove broken lifecycle event handling.
      • Glutin can now be used on Android, however, the application must ensure it only creates the Context following a winit Event::Resumed event, and destroys the Context in response to a Event::Suspended event.
    • Updated winit dependency to 0.27.0. See winit's CHANGELOG for more info.
    • On Windows, build_raw_context now uses isize for hwnd to follow winit change.
    Source code(tar.gz)
    Source code(zip)
  • v0.28.0(Dec 2, 2021)

  • v0.27.0(Jun 22, 2021)

  • v0.26.0(Dec 10, 2020)

  • v0.25.1(Oct 9, 2020)

  • v0.25.0(Oct 2, 2020)

  • v0.21.0(May 3, 2019)

    • Added treat_as_current function.
    • Breaking: Replaced CreationErrorPair enum variant with CreationErrors.
    • Added Clone to ContextBuilder.
    • Added headless example.
    • Removed internal code relating to libcaca.
    • Implemented Debug on all public facing types.
    • Dropping contexts on platforms using egl and/or glx no longer resets the current context, if the context dropped wasn't the current context.
    • Added context sharing support to MacOS.
    • Breaking: Removed ContextTrait.
    • Breaking: Renamed OsMesaContextExt to HeadlessContextExt. Added functions for using egl-surfaceless.
    • Breaking: Changed WindowedContext and RawContext into typedefs of ContextWrapper.
    • Breaking: Removed new_windowed and new_headless from WindowedContext and Context, respectively.
    • Breaking: Added two new types, NotCurrent and PossiblyCurrent, which RawContext, WindowedContext, ContextBuilder and Context are now generic over.
    • Added {make,treat_as}_not_current function to {Raw,Windowed,}Context.
    • We now load libGL.so instead of libGLX.so.
    • Fixed bug where we drop the hidden window belonging to a headless context on on X11 and/or Wayland before the actual context.
    • "Fixed" bug where we will close EGLDisplays while they are still in use by others. Angry and/or salty rant can be found in glutin/src/api/egl/mod.rs, you can't miss it.
    • Breaking: WindowedContexts now deref to Context, not Window. Please use .window() to access the window.
    Source code(tar.gz)
    Source code(zip)
  • v0.20.0(Apr 2, 2019)

    • We no longer load libEGL.so and libGL.so multiple times.
    • Fixes Context::is_current incorrectly returning false.
    • Made ContextBuilder's pf_reqs public.
    • Breaking: Renamed GlContext{,Ext} to ContextTrait{,Ext}.
    • Breaking: Renamed GlWindow to WindowedContext.
    • Implemented context sharing support for Windows and Linux.
    • Added support for contexts made from raw parts for Windows and Linux.
    • Breaking: Removed shareable_with_windowed_contexts. Now you must build OsMesa contexts via a separate extension.
    • Added ContextBuilder::build_{windowed,headless} methods.
    • Breaking: Renamed Context::new to Context::new_headless. new_headless now accepts dimensions for the off-screen surface backing it.
    • Breaking: Renamed GlWindow::new to WindowedContext::new_windowed.
    • On X11 and Wayland, you can now use shared contexts, however, one limitation of the Wayland backend is that all shared contexts must use the same events pool as each other.
    • Added context sharing support to windows.
    • Improved docs.
    • Refactored code to be more consistent/cleaner. Ran rustfmt on everything.
    • Added NetBSD support.
    • Breaking: Removed new_shared function from Context and GlWindow, in favor of new.
    • Added build method to ContextBuilder.
    • Added get_egl_display method to GlContextExt trait and its implementation for platforms.
    • Removed minimum supported Rust version guarantee.
    • NoBackendAvailable is now Sync, as a result CreationError is also Sync.
    • Update winit dependency to 0.19.0. See winit's CHANGELOG for more info.
    Source code(tar.gz)
    Source code(zip)
  • v0.19.0(Nov 10, 2018)

    • Breaking: The entire API for headless contexts has been removed. Please instead use Context::new() when trying to make a context without a visible window. Also removed headless feature.
    • Breaking: Types implementing the GlContext trait must now be sized.
    • Breaking: Added new CreationErrorPair enum variant to enum CreationError.
    • Remove requirement for EGL dev packages on Wayland.
    • Update winit dependency to 0.18.0. See winit's CHANGELOG for more info.
    Source code(tar.gz)
    Source code(zip)
  • v0.18.0(Aug 3, 2018)

    • cocoa and core-graphics updates.
    • Breaking: Added OsError variant to ContextError.
    • Improved glX error reporting.
    • The iOS backend no longer fails to compile... again (added iOS testing on CI to prevent further issues).
    • Update winit dependency to 0.17.0. See winit's CHANGELOG for more info.
    Source code(tar.gz)
    Source code(zip)
  • v0.17.0(Jun 28, 2018)

    • Fix regression that prevented automatic graphics switching in MacOS (#980)
    • Add ContextBuilder::with_double_buffer function
    • Add ContextBuilder::with_hardware_acceleration function
    • Work around a presumed Android emulator bug that would cause context creation to return CreationError::OpenGlVersionNotSupported in some configurations (#1036)
    • Update winit dependency to 0.16.0. See winit's CHANGELOG for more info.
    • The iOS backend no longer fails to compile.
    Source code(tar.gz)
    Source code(zip)
Owner
Rust Windowing
Assorted Windowing Stuff, in Rust
Rust Windowing
Rust-and-opengl-lessons - Collection of example code for learning OpenGL in Rust

rust-and-opengl-lessons Project requires Rust 1.31 Collection of example code for learning OpenGL in Rust 00 - Setup 01 - Window 02 - OpenGL Context 0

Nerijus Arlauskas 348 Dec 11, 2022
Text Renderer written in Rust using HarfBuzz for shaping, FreeType for rasterization and OpenGL for rendering.

Provok Text Renderer written in Rust using HarfBuzz for shaping, FreeType for rasterization and OpenGL for rendering. Input Provok is fed with a JSON

Ossama Hjaji 67 Dec 10, 2022
A low-level gltf parser implemented on nanoserde

Goth-gltf aims to be a low-level, unopinionated reader for glTF files. In comparison with gltf-rs, it: Represents the glTF JSON structure transparentl

Ashley 18 Dec 27, 2022
Vel: A language for verified low-level software

Vel A language for verified low-level software. It dreams to be something like Rust with logic ― a language that empowers people to build verified low

Higher-Order Program Verification 9 Jan 26, 2023
A direct ecs to low-level server implementation for Godot 4.1

godot_ecs What if Godot 4.1 and Bevy got married? Well, you'd get one interesting duo of data driven goodness. In Development This crate is not produc

null 5 Oct 6, 2023
Bindings to TinyGL, a Small, Free and Fast Subset of OpenGL

TinyGL is a very lightweight partial OpenGL implementation. Its small size makes it ideal for static linking.

null 12 Oct 13, 2022
Vulkan and Rust rendering~game engine which creation is covered with YouTube videos

Vulkan and Rust rendering~game engine which creation is covered with YouTube videos

小鳥 11 Dec 4, 2022
Motion graphics creation tool in Bevy. (Highly inspired by Motion Canvas and Manim)

Bevy MotionGfx Bevy Motiongfx is a motion graphics creation tool in Bevy. It is highly inspired by Motion Canvas & Manim. Goal The goal of this tool i

Nixon 3 Nov 6, 2023
A simple camera for properly displaying tile-based low resolution pixel perfect 2D games in bevy.

Bevy Tiled Camera A simple camera for properly displaying low resolution pixel perfect 2D games in bevy. The camera will adjust the viewport to scale

sark 10 Oct 5, 2022
An interactive, low-boilerplate creative coding platform

nightgraph A creative coding platform in Rust. Provides drawing APIs, a CLI, Native and WASM GUIs, and low-boilerplate artwork creation. Designed init

Kyle Kneitinger 21 Oct 3, 2022
Extreme Bevy is what you end up with by following my tutorial series on how to make a low-latency p2p web game.

Extreme Bevy Extreme Bevy is what you end up with by following my tutorial series on how to make a low-latency p2p web game. There game can be played

Johan Klokkhammer Helsing 39 Jan 5, 2023
RPG Dialog support for Bevy, written in pure Rust!

?? ?? Bevy x RPG Dialog ?? ?? RPG Dialog support for Bevy, written in pure Rust! bevy-rpg is a plugin crate that adds dialog functionalities to Bevy,

null 5 Jan 8, 2023
unrust - A pure rust based (webgl 2.0 / native) game engine

unrust A pure rust based (webgl 2.0 / native) game engine Current Version : 0.1.1 This project is under heavily development, all api are very unstable

null 368 Jan 3, 2023
Multi-channel signed distance field (MSDF) generator for fonts implemented in pure Rust.

msdfont WIP - school started so less updates from now on :(( Multi-channel signed distance field (MSDF) generator for fonts implemented in pure Rust.

Leon 3 Aug 29, 2022
Pure C Game Engine

Corange game engine Version 0.8.0 Written in Pure C, SDL and OpenGL. Running Corange is a library, but to take a quick look at some of the things it d

Daniel Holden 1.6k Jan 3, 2023
Pure and simple Vulkan bindings generated from Vulkan-Headers!

mira Pure and simple Vulkan bindings generated from Vulkan-Headers! Mira provides a simple and straightforward way to interact with Vulkan. Everything

maresia 3 Mar 3, 2022
Pure, minimal, and scalable timers

timer-queue A pure, minimal, and scalable structure for tracking expiration of timers let mut q = TimerQueue::new(); q.insert(42, "second"); q.insert(

Benjamin Saunders 18 Nov 15, 2022
FPS library for gdnative written in Rust.

gd_rusty_fps FPS library for gdnative written in Rust. This projects aims to create easy to use .dll library to be used with godot engine for FPS game

null 1 Jan 4, 2022
Pleco is a chess Engine & Library derived from Stockfish, written entirely in Rust

Pleco Pleco is a chess Engine & Library derived from Stockfish, written entirely in Rust. This project is split into two crates, pleco, which contains

Stephen Fleischman 225 Dec 18, 2022