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!

    type: bug status: wontfix platform: Windows status: upstream 
    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

    To-Close-For-Inactivity 
    opened by cactorium 29
  • 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.

    type: bug platform: X11 To-Close-For-Inactivity 
    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?).

    type: bug platform: Wayland difficulty: hard status: waiting priority: low 
    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

    [email protected]:~/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)
    
    type: bug platform: X11 status: waiting status: upstream 
    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.

    type: question 
    opened by bitshifter 22
  • Enabling multisampling returns error when it shouldn't.

    Enabling multisampling returns error when it shouldn't.

    Only recently, when I use with_multisampling in my glutin/glium project I get the error `Couldn't find any pixel format that matches the criterias.'

    This never used to happen before, and in fact, multisampling is supported (and worked) on the computer that I'm testing on!

    type: bug platform: X11 
    opened by TyOverby 22
  • Fix example crashing on linux with LLVMpipe Driver

    Fix example crashing on linux with LLVMpipe Driver

    • to fix crashing on linux with LLVMpipe Driver (and possibly other ancient drivers) turn off window transparency by default.

    RUST_LOG:

    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { raw_code: Some(8), raw_os_message: Some("BadMatch (invalid parameter attributes)"), kind: BadMatch }', glutin_examples/src/lib.rs:135:61
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    
    opened by ar37-rs 2
  • 0.30 beta2, Linux, thread 'main' panicked at  gl_window.surface.swap_buffers(&gl_context).unwrap();

    0.30 beta2, Linux, thread 'main' panicked at gl_window.surface.swap_buffers(&gl_context).unwrap();

    Remote connect to a Ubuntu 22.04 run on window server VM, 4G memory.

    RUST_BACKTRACE=1 cargo run --example window Finished dev [unoptimized + debuginfo] target(s) in 0.06s Running /home/lion/opensrc/glutin/target/debug/examples/window Picked a config with 0 samples Running on llvmpipe (LLVM 13.0.1, 256 bits) OpenGL Version 4.5 (Core Profile) Mesa 22.0.5 Shaders version on 4.50 thread 'main' panicked at 'called Result::unwrap() on an Err value: Error { raw_code: Some(8), raw_os_message: Some("BadMatch (invalid parameter attributes)"), kind: BadMatch }', glutin_examples/examples/window.rs:126:61 stack backtrace: 0: rust_begin_unwind at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5 1: core::panicking::panic_fmt at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14 2: core::result::unwrap_failed at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/result.rs:1805:5 3: core::result::Result<T,E>::unwrap at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/result.rs:1098:23 4: window::main::{{closure}} at ./examples/window.rs:126:17 5: winit::platform_impl::platform::sticky_exit_callback at /home/lion/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/winit-0.27.2/src/platform_impl/linux/mod.rs:849:9 6: winit::platform_impl::platform::x11::EventLoop::run_return::single_iteration at /home/lion/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/winit-0.27.2/src/platform_impl/linux/x11/mod.rs:390:17 7: winit::platform_impl::platform::x11::EventLoop::run_return at /home/lion/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/winit-0.27.2/src/platform_impl/linux/x11/mod.rs:448:31 8: winit::platform_impl::platform::x11::EventLoop::run at /home/lion/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/winit-0.27.2/src/platform_impl/linux/x11/mod.rs:503:25 9: winit::platform_impl::platform::EventLoop::run at /home/lion/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/winit-0.27.2/src/platform_impl/linux/mod.rs:755:56 10: winit::event_loop::EventLoop::run at /home/lion/.cargo/registry/src/mirrors.sjtug.sjtu.edu.cn-4f7dbcce21e258a2/winit-0.27.2/src/event_loop.rs:278:9 11: window::main at ./examples/window.rs:99:5 12: core::ops::function::FnOnce::call_once at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:248:5

    eglinfo & glxinfo see attached file

    opengl_info.txt

    platform: X11 
    opened by golanguage 2
  • Move to `objc2`

    Move to `objc2`

    Helps with following Cocoa's memory management rules (for example, https://github.com/rust-windowing/glutin/pull/1453 wouldn't have happened with this) - and while I was at it, I fixed a few C enum definitions (objc2's verify_message feature is a great help with that).

    See commit messages for details.

    • [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
    type: bug type: enhancement platform: macOS 
    opened by madsmtm 3
  • Any examples of using Glutin to create a single context that may be used with multiple windows over its lifetime.

    Any examples of using Glutin to create a single context that may be used with multiple windows over its lifetime.

    Hi, I'm trying to update egui/eframe to better support Android by lazily creating graphics state when applications first resume and on android it would destroy and recreate surface state when the application is Paused and Resumed.

    I've been able to get egui/eframe working like this on Android when running with wgpu and the same should be possible with gles + egl but I'm currently not really clear on how I can do this with the Glutin API.

    My impression is that Glutin tightly couples GL contexts with windows which seems surprising to me, and I'm unsure at the moment how to practically create a context that's initially not associated with any windows/surfaces and then separately be able to create and destroy windows to use with that context. It would also be OK if the context is initially created with an associated window but I'd still like to be able to freely destroy and create other windows later that would be used with the original context that shouldn't need to be destroyed.

    Ideally I'm also looking for an approach that will work consistently across platforms; avoiding the need to handle Android as a special case. (So if possible I'd like to avoid needing to create a RawContext type of escape hatch just for Android)

    A few things I have seen:

    I've seen that a window can be "split" from a glutin context but also saw the surprising safety warning that if the window is destroyed then the context should be destroyed first which I found counter intuitive. I also haven't seen how you can do the opposite and attach a window to a context. I think I would have expected that Context::make_current() would have taken some form of WindowSurface argument that would allow contexts and window surfaces to be managed separately.

    I've seen the multiwindow example which isn't quite what I'm looking for here since that seems to create a separate context for each window which shouldn't be necessary here (and also implies re-creating GL state, such as uploading textures which isn't desirable).

    I've also seen the rawcontext type that represents a context that's associated with a window that was created externally which doesn't seem applicable. In this case I'd still like Glutin to handle creating window surfaces.

    In the Context docs I see it says "however Contexts can be shared between multiple windows" which does suggest that it is possible to do what I'm looking for so maybe I'm currently just missing a trick somewhere?

    Maybe there's even some example app somewhere that shows how this kind of use case can be handled?

    Any pointers would be much appreciated!

    opened by rib 7
Releases(v0.30.0-beta.2)
  • 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 340 Sep 14, 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 Jun 30, 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 2 Aug 30, 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

小鳥 7 Sep 11, 2022
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 13 Mar 30, 2022
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 9 Aug 18, 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 20 Aug 11, 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 20 Sep 7, 2022
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 365 Aug 10, 2022
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.5k Sep 23, 2022
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
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 208 Aug 30, 2022
A no-frills Tetris implementation written in Rust with the Piston game engine, and Rodio for music.

rustris A no-frills Tetris implementation written in Rust with the Piston game engine, and Rodio for music. (C) 2020 Ben Cantrick. This code is distri

Ben Cantrick 17 Aug 18, 2022
A tool to generate inbetweens for animated sprites, written in godot-rust

Bitmapflow is a tool to help you generate inbetweens for animated sprites. In other words, it makes your animations smoother. It uses optical flow to

null 405 Sep 18, 2022
Rustcraft is a simple Minecraft engine written in rust using wgpu.

Rustcraft is a simple Minecraft engine written in rust using wgpu.

Raphael Van Hoffelen 106 Sep 2, 2022
rpg-cli is a bare-bones JRPG-inspired terminal game written in Rust

rpg-cli is a bare-bones JRPG-inspired terminal game written in Rust. It can work as an alternative to cd where you randomly encounter enemies as you change directories.

Facundo Olano 660 May 27, 2021
Walleye is a chess engine written completely in rust.

Walleye is a UCI-compatible engine written using the classical alpha-beta style AI. It supports loading board positions from arbitrary FEN strings, Unicode pretty printing to the console, and UCI communication logs to help with debugging.

Mitchel Paulin 91 Sep 12, 2022