gfx VS glium

Understand Wayland concepts: Familiarize yourself with the basic concepts and principles of Wayland. This will help you gain a solid understanding of how the system works. You can refer to the official Wayland documentation (https://wayland.freedesktop.org/docs/html/) and the Wayland book (https://wayland-book.com/). Learn Rust: If you're not already proficient in Rust, take some time to learn the language. The Rust Book (https://doc.rust-lang.org/book/) is a great place to start. Study existing Wayland compositors: Since you mentioned Anvil and smallvil, you can study their source code to gain insights into how they're designed and implemented. Try to understand the structure and how different components interact with each other. Dive into Smithay: Smithay (https://github.com/Smithay/smithay) is a Rust library for building Wayland compositors. Familiarize yourself with the library and its components. You can start by studying the provided examples and reading the API documentation. Learn graphics programming: Since you're interested in graphics effects, you'll need to learn about graphics programming concepts, such as shaders, framebuffers, and texturing. Vulkan (https://www.vulkan.org/) is a popular graphics API that you can use with Rust. Check out the following resources to learn more about Vulkan and graphics programming in Rust: Vulkan Tutorial (https://vulkan-tutorial.com/) gfx-rs (https://github.com/gfx-rs/gfx), a Rust graphics library Vulkano (https://github.com/vulkano-rs/vulkano), a safe, pure-Rust wrapper around the Vulkan API Start small: Break down the compositor project into smaller, manageable tasks. Begin by implementing basic functionality, like setting up a window and drawing simple shapes. Gradually add more features, such as input handling and window management. Ask for help: Join the Wayland and Rust communities to ask questions and seek advice. You can find them on forums, mailing lists, and chat platforms like Discord or IRC. The Wayland mailing list (https://lists.freedesktop.org/mailman/listinfo/wayland-devel) and the Rust programming subreddit (https://www.reddit.com/r/rust/) are good places to start. Iterate and experiment: As you progress, keep experimenting with different graphics effects and shaders. Try to implement the features you're interested in, such as blur, window previews, and window switching.

For users of old school crate _gfx_ v0.18 I have PRs that will fix this issue without any additional changes (https://github.com/gfx-rs/gfx/pull/3791) though I suppose there aren't too many such users nowadays...

The gfx-backend-* READMEs each have a graphic explanation that is very useful. As others have said, the best way to handle this is with a flipped viewport, but I've never seen a satisfactory explanation as to why this doesn't mess with front/back faces and culling.

From https://github.com/gfx-rs/gfx

https://github.com/gfx-rs/gfx#hardware-abstraction-layer

Searching through the source code for wgpu and its dependencies, the error is coming from the gfx-rs DirectX 11 backend. I am guessing this is because of a limitation of DirectX 11. The easiest thing to do would probably be to try switching to the DirectX 12 or Vulkan backends.

Looks like they are using https://github.com/ggez/ggez which in turn uses https://github.com/gfx-rs/gfx for low-level drawing to the screen

There is also gfx-rs, which should be easier to use than opengl.

https://crates.io/crates/tiny-skia

You can put things together pretty easily with these libs. And they also let you skip the gpu boilerplate (I should note that tiny-skia works only in the CPU).

Lastly, you have shader programming (OpenGL, Vulkan, etc.). If you're writing "production code" you'll have to do some setting up of the GPU, and the actual graphics code will be in a separate shader language. Shader languages are similar to C but with restrictions that allow for a high level of parallism, making it extremely fast. If you want to get started with this I'd recommend playing around on a site like shadertoy[1] where you can start writing shaders right away. I haven't done much of this myself but as far as Rust goes I've seen a lot of references to the gfx crate:

https://crates.io/crates/gfx

I hope this helps

[1] https://www.shadertoy.com/

I am trying to follow to this tutorial on glium and I can't even get a window to show up because of what I assume to be a lack of comprehension on my end about how dependencies work.

Which is blocked, waiting for glium to update: https://github.com/glium/glium/pull/2036

https://crates.io/crates/glium (8 months ago - 925 kB)

The book is a great place to look at https://github.com/glium/glium/tree/master/book And glium itself is a bit outdated might be good to look at alternatives like glow

Hi rustaceans! I glued this prototype together with vtkio and glium. There are more features that are unsupported than supported at this point, but the code is here if you want to check it out: https://github.com/JeffIrwin/skillet

https://github.com/glium/glium/issues/941 is the relevant Glium bug/feature request. Long story short, structs as uniforms aren't supported by Glium's current design, it looks like.

Should i learn glium (https://crates.io/crates/glium)? i have some experience in opengl (C++) and i would like to use the opengl functionality in the Rust ecosystem.

I can recommend https://github.com/glium/glium as a good, safe abstraction. There was a time when I wanted to learn shaders and write complex pipelines with several stages, this library allowed me to learn about the important objects and their responsibilities without having to program the very verbose chunks of code to initialize. I learned the following:

Glium is a Rust-y OpenGL wrapper, and its repository contains a discussion that should give you an idea whether this is what you want to use, as well as some tutorial.

With a gluim window open, I want to count the number of user clicks and retain the number after the window is closed. In order to keep the program running after the window is closed, I had to change event_loop.run to event_loop.run_return and I think that means all variables will be moved into the closure and my counter goes out of scope.