Safe OpenGL wrapper for the Rust language.

Related tags

Graphics rust opengl
Overview

glium

Build Status Coverage Status

crates.io page

Note to current and future Glium users:

Glium is no longer actively developed by its original author. That said, PRs are still welcome and maintenance is continued by the surrounding community.

Elegant and safe OpenGL wrapper.

Glium is an intermediate layer between OpenGL and your application. You still need to manually handle the graphics pipeline, but without having to use OpenGL's old and error-prone API.

[dependencies]
glium = "*"

Its objectives:

  • Be safe to use. Many aspects of OpenGL that can trigger a crash if misused are automatically handled by glium.
  • Provide an API that enforces good practices such as RAII or stateless function calls.
  • Be compatible with all OpenGL versions that support shaders, providing a unified API when things diverge.
  • Avoid all OpenGL errors beforehand.
  • Produce optimized OpenGL function calls, and allow the user to easily use modern OpenGL techniques.

Link to the documentation

If you have some knowledge of OpenGL, the documentation and the examples should get you easily started.

Link to a work-in-progress tutorial

Why should I use Glium instead of raw OpenGL calls?

Easy to use:

  • Functions are higher level in glium than in OpenGL. Glium's API tries to be as Rusty as possible, and shouldn't be much different than using any other Rust library. Glium should allow you to do everything that OpenGL allows you to do, just through high-level functions. If something is missing, please open an issue.

  • You can directly pass vectors, matrices and images to glium instead of manipulating low-level data.

  • Thanks to glutin, glium is very easy to setup compared to raw OpenGL.

  • Glium provides easier ways to do common tasks. For example the VertexBuffer struct contains information about the vertex bindings, because you usually don't use several different bindings with the same vertex buffer. This reduces the overall complexity of OpenGL.

  • Glium handles framebuffer objects, samplers, and vertex array objects for you. You no longer need to create them explicitly as they are automatically created when needed and destroyed when their corresponding object is destroyed.

  • Glium is stateless. There are no set_something() functions in the entire library, and everything is done by parameter passing. The same set of function calls will always produce the same results, which greatly reduces the number of potential problems.

Safety:

  • Glium detects what would normally be errors or undefined behaviors in OpenGL, and panics, without calling glGetError which would be too slow. Examples include requesting a depth test when you don't have a depth buffer available, not binding any value to an attribute or uniform, or binding multiple textures with different dimensions to the same framebuffer.

  • If the OpenGL context triggers an error, then you have found a bug in glium. Please open an issue. Just like Rust does everything it can to avoid crashes, glium does everything it can to avoid OpenGL errors.

  • The OpenGL context is automatically handled by glium. You don't need to worry about thread safety, as it is forbidden to change the thread in which OpenGL objects operate. Glium also allows you to safely replace the current OpenGL context with another one that shares the same lists.

  • Glium enforces RAII. Creating a Texture2d struct creates a texture, and destroying the struct destroys the texture. It also uses Rust's borrow system to ensure that objects are still alive and in the right state when you use them. Glium provides the same guarantees with OpenGL objects that you have with regular objects in Rust.

  • High-level functions are much easier to use and thus less error-prone. For example there is no risk of making a mistake while specifying the names and offsets of your vertex attributes, since Glium automatically generates this data for you.

  • Robustness is automatically handled. If the OpenGL context is lost (because of a crash in the driver for example) then swapping buffers will return an error.

Compatibility:

  • In its default mode, Glium should be compatible with both OpenGL and OpenGL ES. If something doesn't work on OpenGL ES, please open an issue.

  • During initialization, Glium detects whether the context provides all the required functionality, and returns an Err if the device is too old. Glium tries to be as tolerant as possible, and should work with the majority of the OpenGL2-era devices.

  • Glium will attempt to use the latest, optimized versions of OpenGL functions. This includes buffer and texture immutable storage and direct state access. It will automatically fall back to older functions if they are not available.

  • Glium comes with a set of tests that you can run with cargo test. If your project/game doesn't work on specific hardware, you can try running Glium's tests on it to see what is wrong.

Performances:

  • State changes are optimized. The OpenGL state is only modified if the state actually differs. For example if you call draw with the IfLess depth test twice in a row, then glDepthFunc(GL_LESS) and glEnable(GL_DEPTH_TEST) will only be called the first time. If you then call draw with IfGreater, then only glDepthFunc(GL_GREATER) will be called.

  • Just like Rust is theoretically slower than C because of additional safety checks, glium is theoretically slower than well-prepared and optimized raw OpenGL calls. However in practice the difference is very low.

  • Fully optimized OpenGL code uses advanced techniques such as persistent mapping or bindless textures. These are hard to do and error-prone, but trivially easy to do with glium. You can easily get a huge performance boost just by doing the right function calls.

  • Since glium automatically avoids all OpenGL errors, you can safely use the GL_KHR_no_error extension when it is available. Using this extension should provide a good performance boost (but it is also very recent and not available anywhere for the moment).

Limitations:

  • Robustness isn't supported everywhere yet, so you can still get crashes if you do incorrect things in your shaders.

  • Glium gives you access to all the tools but doesn't prevent you from doing horribly slow things. Some knowledge of modern techniques is required if you want to reach maximum performances.

  • Glium pushes the Rust compiler to its limits. Stack overflows (inside the compiler), internal compiler errors, one-hour compile time, etc. happen more often than in smaller libraries.

  • Rust plugins are not stable, so you will have to use macros such as implement_vertex!(MyStruct) instead of #[derive(GliumVertex)].

Comments
  • Add support for loading SPIR-V shaders

    Add support for loading SPIR-V shaders

    This PR adds support for SPIR-V shader loading to glium (with OpenGL >= 4.6 or extension ARB_gl_spirv). You can see it in action by running the spirv example.

    For this I added a new variant ProgramCreationInput::SpirV.

    Fixes: https://github.com/glium/glium/issues/1890

    opened by Boscop 25
  • How to render to Android's SurfaceTexture

    How to render to Android's SurfaceTexture

    Looking at a pure-rust android example https://github.com/kmcallister/azurescens/blob/master/src/main.rs#L153 we see that we need to pass a Facade, which is a display built from a WindowBuilder. What if I want to NOT use any Android windowing and instead render to an android's SurfaceTexture? Is it possible to get a display from a SurfaceTexture?

    T-enhancement 
    opened by lattice0 22
  • AppKit not being called from main thread

    AppKit not being called from main thread

    I'm not sure how to handle this in a cross platform manner, but calling any AppKit method on a background thread is disallowed and undefined behavior (And Glium uses exclusively that)

    This is a possible cause of the Glium examples beach-balling on Mac.

    Note: I'm posting this to both Glium and Glutin's pages, as I'm not sure where it's best to solve this.

    https://github.com/tomaka/glutin/issues/245

    os/x 
    opened by mystise 20
  • Basic triangle drawing not working on OSX

    Basic triangle drawing not working on OSX

    This is not the triangles drawing example that you have in glium, it's a triangle program that I built in my engine.

    When running the program normally, nothing shows up on the screen. When I inserted a bunch of calls to assert_no_errors, I get GL_INVALID_OPERATION after a call to frame.draw.

    There should be minor differences between how my triangles.rs example and your triangles.rs example do things under the scene, so I wonder if you can deduce anything.

    Trace file here: https://www.dropbox.com/s/lsa63yj35hso69e/triangle.trace?dl=0

    T-bug 
    opened by TyOverby 19
  • OpenGL not loaded correctly on OSX

    OpenGL not loaded correctly on OSX

    I've seen this complaint on #rust-gamedev, but I didn't see a bug for it, so here's what I get on my late-2014 macbook pro.

    thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: OpenGlError("OpenGL implementation doesn\'t support vertex array objects\nOpenGL implementation doesn\'t support sampler objects")', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/libcore/result.rs:742
    
    T-enhancement os/x 
    opened by TyOverby 19
  • Test fails on Windows 8.1 64-bit - GL_INVALID_OPERATION error generated. <framebuffer> is not a valid framebuffer object.

    Test fails on Windows 8.1 64-bit - GL_INVALID_OPERATION error generated. is not a valid framebuffer object.

    T:\Data\Projects\glium>cargo test --verbose
           Fresh compile_msg v0.1.3 (https://github.com/huonw/compile_msg#b19da50c)
           Fresh bitflags v0.1.0
           Fresh glium_macros v0.0.1 (file:///T:/Data/Projects/glium)
           Fresh khronos_api v0.0.5
           Fresh rustc-serialize v0.2.10
           Fresh log v0.2.1
           Fresh gl_common v0.0.3
           Fresh winapi v0.1.6
           Fresh xml-rs v0.1.16
           Fresh num v0.1.10 (https://github.com/rust-lang/num#c05cd530)
           Fresh cgmath v0.0.1 (https://github.com/bjz/cgmath-rs#9bb0f789)
           Fresh nalgebra v0.2.2 (https://github.com/sebcrozet/nalgebra#14df1380)
           Fresh kernel32-sys v0.0.5
           Fresh gdi32-sys v0.0.3
           Fresh user32-sys v0.0.5
           Fresh gl_generator v0.0.13
           Fresh image v0.2.0-alpha.8 (https://github.com/PistonDevelopers/image#b29
    d0706)
           Fresh glutin v0.0.4-pre (http://github.com/tomaka/glutin#be092183)
           Fresh glium v0.0.2 (file:///T:/Data/Projects/glium)
         Running `T:\Data\Projects\glium\target\attrs-96fa59aaedf34481.exe`
    
    running 9 tests
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    test attribute_vec2_tuple ... ok
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    test attribute_types_mismatch ... ok
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    test attribute_float ... ok
    test attribute_vec2 ... ok
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    test attribute_vec3_tuple ... ok
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    test attribute_vec3 ... ok
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    test attribute_vec4 ... ok
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    test attribute_vec4_tuple ... ok
    test missing_attribute ... ok
    
    test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured
    
         Running `T:\Data\Projects\glium\target\backface-culling-53f05dbce04756d9.ex
    e`
    
    running 4 tests
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    thread 'glium rendering thread' panicked at 'Debug message with high or medium s
    everity: `GL_INVALID_OPERATION error generated. <framebuffer> is not a valid fra
    mebuffer object.`.
    Please report this error: https://github.com/tomaka/glium/issues', src\lib.rs:16
    56
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    thread 'glium rendering thread' panicked at 'Debug message with high or medium s
    everity: `GL_INVALID_OPERATION error generated. <framebuffer> is not a valid fra
    mebuffer object.`.
    Please report this error: https://github.com/tomaka/glium/issues', src\lib.rs:16
    56
    stack backtrace:
       1:         0x69bec62b - sys::backtrace::write::h5d8eeb6b31ece965cqu
       2:         0x69c026eb - rt::unwind::register::h49d2602058168ec5c7A
       3:         0x69b8360f - rt::unwind::begin_unwind_inner::h1772a00c8d230691N4A
       4:         0x69b83dd1 - rt::unwind::begin_unwind_fmt::h84a2c35fac0712d0j3A
       5:         0x69c01d9a - rust_begin_unwind
       6:         0x69c17489 - panicking::panic_fmt::had385503c1077d42BRv
       7:           0x49425b - main
       8:           0x5fdadf - main
       9:           0x5f5a74 - main
      10:           0x5f3d55 - main
      11:           0x568ede - main
      12:           0x568e79 - main
      13:           0x44c3a9
      14:           0x44c36d
      15:           0x4830e1
      16:         0x6979f65e - Bencher::ns_per_iter::h22bba3f257e5ac85udc
      17:         0x697a87d9 - Bencher::ns_per_iter::h22bba3f257e5ac85udc
      18:         0x697a0034 - Bencher::ns_per_iter::h22bba3f257e5ac85udc
      19:         0x697a057a - Bencher::ns_per_iter::h22bba3f257e5ac85udc
      20:         0x69c2f46c - rust_try
      21:         0x69c2f449 - rust_try
      22:         0x697a0baf - Bencher::ns_per_iter::h22bba3f257e5ac85udc
      23:         0x69bf2e12 - sys::time::_&'a SteadyTime.Sub::sub::h818476a6d1b7066
    augx
      24:     0x7ff86d9213d2 - BaseThreadInitThunk
    thread panicked while panicking. aborting.
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    Debug message: `Buffer detailed info: Buffer object 2 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    thread 'glium rendering thread' panicked at 'Debug message with high or medium s
    everity: `GL_INVALID_OPERATION error generated. <framebuffer> is not a valid fra
    mebuffer object.`.
    Please report this error: https://github.com/tomaka/glium/issues', src\lib.rs:16
    56
    Debug message: `Buffer detailed info: Buffer object 1 (bound to GL_ARRAY_BUFFER_
    ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffe
    r object operations.`
    stack backtrace:
       1:         0x69bec62b - sys::backtrace::write::Debug message: `Buffer detaile
    d info: Buffer object 2 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_D
    RAW) will use VIDEO memory as the source for buffer object operations.`
    h5d8eeb6b31ece965cqu
       2:         0x69c026eb - rt::unwind::register::h49d2602058168ec5c7A
       3:         0x69b8360f - rt::unwind::begin_unwind_inner::h1772a00c8d230691N4A
       4:         0x69b83dd1 - rt::unwind::begin_unwind_fmt::h84a2c35fac0712d0j3A
    thread 'glium rendering thread' panicked at 'Debug message with high or medium s
    everity: `GL_INVALID_OPERATION error generated. <framebuffer> is not a valid fra
    mebuffer object.`.
    Please report this error: https://github.com/tomaka/glium/issues', src\lib.rs:16
    56
       5:         0x69c01d9a - rust_begin_unwind
       6:         0x69c17489 - panicking::panic_fmt::had385503c1077d42BRv
       7:           0x49425b - main
       8:           0x5fdadf - main
       9:           0x5f5a74 - main
      10:
    
    T:\Data\Projects\glium>rustc --version
    rustc 1.0.0-nightly (52c74e63d 2015-01-29 22:54:19 +0000)
    

    GPU: Geforce GTX 660 Ti

    T-bug 
    opened by isurakka 18
  • Add support for importing Vulkan textures

    Add support for importing Vulkan textures

    As a continuation of my previous work, where I added semaphore import in #1939, I've been working on adding the possibility to import Vulkan textures into Glium.

    This MR adds the functionality of the EXT_external_objects into Glium.

    In Vulkan, textures and memory are separate concepts. Thus, in order to conform to this, the aforementioned extension introduces the concept of memory objects in OpenGL. These external memory objects can be used to create OpenGL textures. Thus, I've added the new_from_fd function to textures, which imports a memory object from an opaque file descriptor and uses that to create GL texture.

    With this functionality, it is now possible to import Vulkan textures, and with the existing Vulkan semaphore support, it is possible to synchronize access to these textures.

    The only remaining issue at the moment is a crash happening with the Intel Iris driver, when flushing the signal semaphore command from the OpenGL side. Running a debug version of the driver, it prints out Failed to submit batchbuffer: Invalid argument. Given that the driver does not pass the piglit vk-semaphores-2 test, this is probably a problem within the Iris driver. I will submit a bug report to the Mesa repository.

    I have created some sample code. This program draws to a shared texture with Glium from another thread, which is the drawn to the window by Vulkano. This texture oscillates between a black and green color. I'm interested to hear how well it works on Nvidia or with other Intel/AMD drivers.

    Related Vulkano MR

    opened by fayalalebrun 15
  • [WIP] Update to the new `EventsLoop` glutin/winit API

    [WIP] Update to the new `EventsLoop` glutin/winit API

    This change is in anticipation of tomaka/glutin#864 which updates to winit's new EventsLoop based API. See the linked PR for details.

    Now that winit Windows require an EventsLoop argument to their build method, the current DisplayBuild trait does not work well with the glutin backend. To compensate for this, the DisplayBuild trait has been implemented for Window itself rather than WindowBuilder, allowing the user to build their glutin Window separately from building their glium Display.

    build, build_debug and rebuild fns have been added to remove the need for uses to import the DisplayBuild trait.

    One problem that arose while making this change is that, now that rebuild_glium no longer has access to the WindowBuilder for the new window, it can no longer insert the .with_shared_lists builder method. I see a couple possible alternatives for this:

    1. Rely on the user calling .with_shared_lists(display.get_window().unwrap()) when building the new window that is to be used for rebuilding the display.
    2. Add a .share_lists(&other_window) method to glutin::Window.
    3. Something else?

    @tomaka I haven't updated the book or Cargo.toml yet as I thought it best to get your thoughts on everything first, but I'm happy to do so once you are happy with the changes.

    opened by mitchmindtree 15
  • Consider creating a

    Consider creating a "glium" organization

    I don't want to give the impression this is my project and only mine, so a "glium" github organization is maybe better.

    On the other hand, I don't see it as absolutely necessary.

    T-discussion 
    opened by tomaka 15
  • Screen goes from -1.0 to 0.5 in x and y.

    Screen goes from -1.0 to 0.5 in x and y.

    I see this with the teapot demo:

    image

    It shows up in programs I make as well. Origin is where the teapot is, which is 0, 0. It should be in the center.

    The actual display seems to go from -1.0 to 0.5 in X and Y.

    I am on Arch Linux. My friend reports this does not happen on windows. This regression was introduced from #1601.

    opened by vadixidav 14
  • Update glutin to 0.18

    Update glutin to 0.18

    Winit 0.16 has a bug that causes crashes on Windows, but if your project uses glium, this can't be fixed because glutin 0.17 depends on winit 0.16.

    This PR resolves this issue by upgrading glutin and fixing an issue with a new error class that emerged.

    Also, I tried to fix a compiler warning about unchecked error return value by panicking (IMHO better than ignoring the error completely).

    Tested by compiling Conrod examples (where I discovered this problem) and verifying that it no longer crashes.

    opened by Lycowolf 13
  • FT: Prevent panicking in unmatched vertex attributes and missing attributes

    FT: Prevent panicking in unmatched vertex attributes and missing attributes

    This is a totally optional point of view.

    With some apps and meshes, the data is already ready to be sent directly to the GPU, but might not match perfectly with the OpenGL Vertex shader, but OpenGL can still handle it and render the meshes correctly.

    Also, missing vertex attributes should not necessarily causes a hard panic. The shader will still run fine with missing data.

    Therefore, maybe it should be better to make panicking under these conditions a feature?

    I've tested removing the panic! calls in my own branch and things work fine for my use case.

    opened by rnd-ash 2
  • `vertex_array_object.rs` VertexAttribPointer stride being set incorrectly

    `vertex_array_object.rs` VertexAttribPointer stride being set incorrectly

    So in my project, I have a mesh file that has the data already ready to be sent to the GPU. I create bindings dynamically, and call VertexBuffer::new_raw. Then, when VertexAttribPointer in vertex_array_object.rs is called, the stride parameter is incorrect.

    Example:

    Vertex attributes (Generated)

     [("position", 0, 0, F16F16F16, false), ("texturelocation", 6, 1, F16F16, false)]
    

    So here we see the vertex consists of 3x F16 for position, and 2x F16 for texture location. This means that each vertex is 5x2 bytes long (10 bytes).

    So I call VertexBuffer::new_raw like so:

    VertexBuffer::new_raw(
                    display,
                    vertex_buffer.as_slice(),
                    Cow::Owned(bindings),
                    10,
                )
    

    Note that vertex_buffer is simply a array of u8 bytes from the file being read into the GPU directly.

    but then, when rendering, the vertex size is ignored and set to 1 instead!

    Call (vertex_array_object.rs)

    ctxt.gl.VertexAttribPointer(1, 2, 5131, 1, 6,)
    

    Note how the 4th parameter here is 1 in the call withint glium? This should be 10 as it is what I set in my vertex stride size.

    opened by rnd-ash 2
  • [Bug] Texture2D does not work on Android

    [Bug] Texture2D does not work on Android

    I believe this is a bug because the exact same code won't work on Android but works in PC, with exception to the context/window creation. For that I'm using @MarijnS95 updates to both glutin/glium because they don't compile for Android

    Here's a minimum verifiable example: https://github.com/lattice0/AndroidNativeSurface/tree/texture (branch is texture) and the same cargo project of the Android project (https://github.com/lattice0/AndroidNativeSurface/tree/texture/android_native_surface) can also be run with cargo run on desktop, where it will produce a pattern in the texture: Screenshot from 2022-07-14 20-52-56 (error is because I did not start the event loop correctly but whatever)

    Screenshot-20220714-213351

    In summary, the following won't work:

                let texture =
                    Texture2d::empty_with_format(&display, format, mipmap, width, height).unwrap();
                let mut data: Vec<Vec<u8>> = Vec::new();
                for i in 0..width {
                    let mut v: Vec<u8> = Vec::new();
                    for j in 0..height {
                        v.push((i * j % 255) as u8);
                    }
                    data.push(v);
                }
    
                texture.write(
                    glium::Rect {
                        left: 0,
                        bottom: 0,
                        width,
                        height,
                    },
                    data,
                );
    

    On Android you can uncomment FragColor to be red so you can see that at least the square is being renderer:

                    void main() {
                        vec4 a = texture(tex, v_tex_coords);
                        FragColor = vec4(a.r,0.0,0.0,1.0);
                        //Uncomment to see that at least rendering the red square works
                        //FragColor = vec4(1.0,0.0,0.0,1.0);
                    },
    
    opened by lattice0 0
  • Texture2d::write in chunks?

    Texture2d::write in chunks?

    https://docs.rs/glium/latest/glium/texture/texture2d/struct.Texture2d.html#method.write only allows for writing an entire image, but on a decoded video, sometimes there are alignment strides so I have to upload in parts (or copy to a vector, which is slow).

    I'm using PixelBuffer because it allows for such thing https://docs.rs/glium/latest/glium/texture/pixel_buffer/struct.PixelBuffer.html#method.as_mut_slice but I also wanted to support uploading to the texture itself without pixel buffers, because the pixel buffer approach currently is not working on Android for some reason.

    Is there a way to upload to a texture2d according to a stride alignment? That is, upload in part?

    opened by lattice0 0
  • Feature request: Implement gl::TEXTURE_RECTANGLE for 2D games

    Feature request: Implement gl::TEXTURE_RECTANGLE for 2D games

    Can't make a 2D game with glium because it does not implement gl::TEXTURE_RECTANGLE textures. gl::TEXTURE_2D does not properly trim sprites out of a sprite sheet.

    opened by jeffbdavenport 0
Releases(v0.13.4)
Owner
null
A vector graphics renderer using OpenGL with a Rust & C API.

bufro A vector graphics renderer using OpenGL with a Rust & C API. A Rust example can be found in examples/quickstart.rs (using glutin). A C example c

Aspect 9 Dec 15, 2022
Safe and rich Rust wrapper around the Vulkan API

Vulkano See also vulkano.rs. Vulkano is a Rust wrapper around the Vulkan graphics API. It follows the Rust philosophy, which is that as long as you do

null 3.6k Jan 3, 2023
GLFW3 bindings and idiomatic wrapper for Rust.

glfw-rs GLFW bindings and wrapper for The Rust Programming Language. Example extern crate glfw; use glfw::{Action, Context, Key}; fn main() { le

PistonDevelopers 546 Jan 3, 2023
A toy ray tracer in Rust

tray_rust - A Toy Ray Tracer in Rust tray_rust is a toy physically based ray tracer built off of the techniques discussed in Physically Based Renderin

Will Usher 492 Dec 19, 2022
A low-overhead Vulkan-like GPU API for Rust.

Getting Started | Documentation | Blog gfx-rs gfx-rs is a low-level, cross-platform graphics and compute abstraction library in Rust. It consists of t

Rust Graphics Mages 5.2k Jan 8, 2023
A complete harfbuzz's shaping algorithm port to Rust

rustybuzz rustybuzz is a complete harfbuzz's shaping algorithm port to Rust. Matches harfbuzz v2.7.0 Why? Because you can add rustybuzz = "*" to your

Evgeniy Reizner 310 Dec 22, 2022
Graph data structure library for Rust.

petgraph Graph data structure library. Supports Rust 1.41 and later. Please read the API documentation here Crate feature flags: graphmap (default) en

null 2k Jan 9, 2023
A graph library for Rust.

Gamma A graph library for Rust. Gamma provides primitives and traversals for working with graphs. It is based on ideas presented in A Minimal Graph AP

Metamolecular, LLC 122 Dec 29, 2022
Simple but powerful graph library for Rust

Graphlib Graphlib is a simple and powerful Rust graph library. This library attempts to provide a generic api for building, mutating and iterating ove

Purple Protocol 177 Nov 22, 2022
Kiss3d - Keep it simple, stupid 3d graphics engine for Rust.

Kiss3d - Keep it simple, stupid 3d graphics engine for Rust.

Sébastien Crozet 1.2k Dec 26, 2022
A cool, fast maze generator and solver written in Rust

MazeCruncher Welcome to maze cruncher! Download Standalone Here Usage To get started, just run the standalone .exe in target/release or compile and ru

null 69 Sep 20, 2022
ASCII 3D-renderer using Ray Marching technique written in Rust with NCurses

pistol ASCII renderer using Ray Marching technique written in Rust ?? with NCurses. This project is a giga-chad compared to my previous attempt to wri

Eugene Sokolov 5 Dec 10, 2022
A high-performance SVG renderer, powered by Rust based resvg and napi-rs.

resvg-js resvg-js is a high-performance SVG renderer, powered by Rust based resvg and napi-rs. Fast, safe and zero dependencies! No need for node-gyp

一丝 744 Jan 7, 2023
A little cross-platform graphics engine written in rust.

Bismuth This is a version of my C++ graphics engine named Bismuth re-written with Rust. My goal is to learn more about the Rust language and make my g

Admiral サイタマ 1 Nov 1, 2021
The library provides basic functions to work with Graphviz dot lang from rust code.

Description The library provides the basic access to the graphs in graphviz format with ability to import into or export from it. Base examples: Parse

Boris 28 Dec 16, 2022
🦀 Rust Graph Routing runtime for Apollo Federation 🚀

Apollo Router The Apollo Router is a configurable, high-performance graph router for a federated graph. Getting started Follow the quickstart tutorial

Apollo GraphQL 502 Jan 8, 2023
Rust bindings to bgfx, a cross-platform, graphics API agnostic

Rust bindings to bgfx, a cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.

Daniel Collin 65 Dec 24, 2022
Graph API client writen in Rust

graph-rs Now available on stable Rust at crates.io graph-rs-sdk = "0.1.0" 0.1.0 and above use stable Rust. Anything before 0.1.0 uses nightly Rust. M

Sean Reeise 56 Jan 3, 2023
Rust library for of graph ensembles

Rust library for random graph ensembles Minimal Rust version: 1.55.0 Implements simple sampling and monte carlo (or rather markov-) steps, that can be

Yannick Feld 2 Dec 14, 2022