if we saw code we could probably tell you why
if 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. Is there a way to force the Window to use SDL (since that's the backend I am targeting)?
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
Dand you mean the former while I thought it meant the latter
LWebGPU in the readme refers to the standardized WebGPU C API
Doh right yeah, my confusion is coming from rust I'm basically treating https://github.com/gfx-rs/wgpu (which wgpu-native runs on) as "an API that has multiple backends, webgpu being one of them", but from silk's side this means a different thing
Lyou are thinking about wgpu wrong
Lit does not have a "webgpu backend"
it is the webgpu API
it is the webgpu API
Dyes it is the webgpu API, but on the web it can either run on top of webgl or on top of actual webgpu support in the browser if it's available
Dbut I get it, I didn't realize it was literally the webgpu api itself
DI thought webgpu was just one of its backends, because I'm currently literally using wgpu on top of webgl/vulkan/directx in my projects, and since webgpu wasn't available until basically today (chrome just added it in stable) I didn't think of it that much
Lthe "webgpu backend" is just a shim for emscripten to pass the calls to the JS API, which then pass down through the browser to the C API
Dmakes sense :>
