Looking for a specific Cross-Platform GUI crate combo

[hallow loom]

For better or worse, the best way for me to learn things is to reinvent the wheel, that's almost the only way i can understand how things work. So because i do not understand how to use GUI frameworks ( eframe iced slint etc... ) I want to sort of make my own, also because i want to have the most artistic freedom possible.

My dream setup is to find something that will handle Windowing, Input and implicit GPU acceleration for me, then let me draw whatever i want using painting functions and shader code. If this works and it is cross-platform, I will happily figure out the rest, like coding the actual GUI components/widgets and the state. I tried using miniquad with skia-safe but i could't get anywhere cause i can't find any education material, and in rare cases i do it will be outdated. ( same problem with winit )

I have also heard that skia-safe is not actually very safe, but i liked the idea that it could handle any graphics API, and that i could use SKSL with any platform + web-style drawing with shapes, strokes, gradients, drop shadows, blurs, etc...

I'm a DSP/Music oriented programmer so graphics and visuals are very new to me, but i'm very interested to dive into this mess for the sake of Artistic Freedom and knowledge!

[digital socket]

Have you looked at nannou?

[hallow loom]

thanks, i did not know about nannou, it seems a bit too bloated but i'll investigate more

[hallow loom]

i did try macroquad, but i'm looking for more options, cause i want to reserve as much CPU power as possible for real time audio processing, that's why i'm looking for the GPU acceleration too, cause it will take most of the graphics weight from the CPU

and game engines like macroquad ( i think ) tie the user input with the framerate. I want the keyboard input to be polled at a way higher rate ( if it's possible ) cause i want the user to be able to play notes using the keyboard ( i'm talking about virtual instruments )

[digital socket]

generally unless you're down at the hardware-driver level input is not polled but delivered as events to your program, so what you want is not so much “high rate” as “not wrapping the events in a polling-style API”

[hallow loom]

so that problem doesn't really exist?

[digital socket]

if you picked the wrong framework you could be stuck with frame-linked polling

but my point is that you are not looking for "I need to be able to do this very frequently" but "nothing stands in the way of the events being delivered to me"

so for example just using a winit event loop yourself, without any special techniques, would work

[hallow loom]

yeah i got that

[digital socket]

though also to avoid hiccups you will want to use a separate thread for drawing (which is a separate matter from how much work is done on the GPU)

wrt drawing, “doing nearly everything on the GPU” is actually a very advanced technique that requires a lot of work to achieve

so you don't want to focus on that so much as making sure that the work the CPU is doing related to drawing is not blocking the main event loop

[hallow loom]

i can't wrap my head around winit, i was thinking about using winit -> graphics api -> skia, but i just can't find any way to learn how to do it

[digital socket]

well, winit is largely separate from graphics

the only place they touch is creating the context/surface that is attached to the winit window

and you don't necessarily have to use winit, but it is the most well-trodden path for windowing in Rust

[hallow loom]

what i think i know is that winit handles windows and user input, then i need to pair it with another crate that will create a graphics context???( idk what i'm saying ) and then use another crate like skia-safe or wgpu to render using that context

[digital socket]

that's kinda the situation if you wanted OpenGL but wgpu is different

[hallow loom]

hey thanks for your time

[digital socket]

wgpu handles the context (Device + Surface) creation, and the bridge between winit (or other windowing) and wgpu is raw-window-handle which is really just passing the info about the window from one to other

and you don't have to touch raw-window-handle yourself, so in practice it looks just like passing Arc<winit::window::Window> to wgpu::Instance::create_surface()

and it Just Works from that point on

and the same thing applies if you use a different library built on the same foundations, for either of those two roles

[hallow loom]

Device refers to the actual GPU interface?

that's my problem, i have no clue what these words mean

[digital socket]

yes, wgpu::Device is your “session” with the GPU. everything you create on the GPU (shaders, textures, etc) belongs to a particular Device

generally you only need one

other graphics libraries might call the same thing a graphics context

[hallow loom]

do you know any good source that explain that stuff like i'm 5 years old?

[digital socket]

anyway, since your goal is focused on audio and GUI, not audio and arbitrary-graphics, it probably makes sense for you to use something on top of wgpu and not wgpu directly

but you might bump into the same concepts depending on which you use

[digital socket]

sorry, my learning strategy is very different and I don't collect those kinds of resources

[hallow loom]

well i don't either haha

[digital socket]

I've got to AFK now; hope this much helps

[hallow loom]

yeah thanks!

no but it could use similar tech maybe?

let's say i'm making a "drum machine" but it's more complicated

at the end if i get too frustrated with this, i'll go for that: either eframe or iced

or maybe slint too

there is also the "immediate" vs "retained" mode choice

with egui/eframe and the rest

is that for web only?

i mean wgsl

is it a shading language?

so it supports all APIs listed by wgpu?

that's nice

how do you learn???

sorry way to general question

but my problem is that i can't find good docs

or i just can't understand the docs