Ithey didnt really work for me, so someone suggested I use GLFW
Lwdym didnt work
Pthat was probably A Bad Suggestion
Por at least for that problem
Pwhat issues were you seeing?
Loh god the @jvyden4ism is spreading
Ithe window wouldn't clear, it would look like it's not responding, and it'd just crash in a bit
IGLFW doesnt do that though
Lweird
Pif we saw code we could probably tell you why
Pthat sounds like you're writing code that blocks the event loop
II think I might still have it on github
Lor calling swapbuffers when windowing already does, that could cause not clearing, but shouldnt crash
Iah I dont have the old code sadly
Lwhere were you asking these problems?
Iidk some server, I was talking a friend who uses Silk.NET
Lwe would highly reccomend using the abstractions, and if you run into the problem again we'll be able to help
Iidk, I've already restructured my code to use GLFW, I might aswell go with it
Panyways
Por GlfwContext rather
Iyeah I found that out by digging into the code
Ialright it works now
GWhen trying to run my code, I get this error:
Unhandled exception. System.PlatformNotSupportedException: GLFW is not supported on this platform.
Dcoming from wgpu and rust land, I noticed silk was linked on the wgpu-native github page, but silk itself doesn't mention wgpu
does that mean that silk doesn't build on wgpu and became its own thing, or does it use the same validation layers and stuff?
what I found a bit surprising is that silk is a lot more than wgpu, as it includes sdl/glfw, openal, etc.
does that mean that silk doesn't build on wgpu and became its own thing, or does it use the same validation layers and stuff?
what I found a bit surprising is that silk is a lot more than wgpu, as it includes sdl/glfw, openal, etc.
Dalso silk mentions a webgpu backend, but not WASM, which makes me a bit confused 
I'm not super knowledgable on the latest WASM/.NET stuff, so not sure if now that webgpu is in stable chrome it means that silk works on the web?
I'm not super knowledgable on the latest WASM/.NET stuff, so not sure if now that webgpu is in stable chrome it means that silk works on the web?
Li think you misunderstand what silk is
Lsilk is just bindings
Land no, we dont support WASM atm
Dah okay, I guess then this link is wrong https://github.com/gfx-rs/wgpu-native#bindings 
since it's in a list of wgpu bindings
since it's in a list of wgpu bindingsDthanks for explaining!
Lno the link is correct
Lbut i dont know what you mean by "backend" here
Dbut if the link is correct, than silk runs on top of wgpu-native?
Dlike, are the vulkan bindings in silk direct vulkan, or through wgpu-native?
Lwhat do you think bindings mean
DC API exposed to C# directly
Lyes
Lwe provide WebGPU bindings
Land other APIs
Dbut wgpu-native is not just webgpu, it runs on top of vulkan, directx12, opengl, etc. no?
Dor do you use wgpu-native just for the webgpu part?
Lyes, im not sure how thats relavent though
DI mean the readme for silk says
but if you're using webgpu through wgpu-native, does that mean I can also get opengl/directx/metal through wgpu-native when using silk?
providing bindings to popular low-level APIs such as OpenGL, OpenCL, OpenAL, OpenXR, GLFW, SDL, Vulkan, Assimp, WebGPU, and DirectX
but if you're using webgpu through wgpu-native, does that mean I can also get opengl/directx/metal through wgpu-native when using silk?
Lwe just call directly into wgpu-native, so you get whatever they support
Dohh I see, I guess I just find the readme confusing a bit because that means I can get for example vulkan directly, or vulkan through wgpu-native but I get it now
but I get it nowLbut the OpenGL/DX/VK in the readme has nothing to do with WebGPU we also bind to those separately
Dyeah that makes sense, but I mean WebGPU and wgpu-native are not the same thing from my understanding? WebGPU is just one of the backends of wgpu-native?
DI guess there's a distinction of "WebGPU the API" and "WebGPU on the web in a browser"
Lwgpu-native is an implementation of the C api of WebGPU
