306: Improve example friendliness: Don't busy-redraw in examples r=kvark a=khoek
Looking around for solid Rust graphics libraries, I was a bit shocked when the `wgpu-rs` examples made my whole X desktop environment in Ubuntu laggy---maximizing/minimizing other windows or moving any of them had very noticeable latency when an example was running.
This almost turned me off, but after playing around I found that this was just because of the
```rust
match event {
event::Event::MainEventsCleared => window.request_redraw(),
...
```
in all of the examples. Trying to add the least code possible I've replaced a `ControlFlow::Poll` with `ControlFlow::WaitUntil(...)` in the event loops and capped the redraws-per-second below 50, which completely solves this problem for me (plus the window resize response on the examples themselves are much improved, etc.).
I was just going for an unintrusive fix---this is by no means a perfect solution, but I think in the worst case it won't be any worse that what was there originally. Plus, I think it will make people like me who try to start by copying an example more likely to stick around in the short term.
Co-authored-by: Keeley Hoek <keeley@hoek.io>
302: Add BufferRange struct for #199 r=kvark a=paulkernfeld
- Use in set_index_buffer
- Use in set_vertex_buffer
- Use in BindingResource
Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
272: Force the wasm32 types to match Send / Sync with the native types r=kvark a=kyren
This is potentially a controversial change so this is just a draft to discuss it.
Currently, when building wgpu on wasm32, none of the interface types are Send or Sync, whereas on any other platform they are generally Send and Sync and this can cause a lot of pain, especially in the presence of async.
This PR is the nuclear option: lie and forcibly declare nearly all interface types to be Send or Send + Sync.
I think I understand the situation with proposed wasm32 threading a bit better now, and as of right now at least with my current understanding, it seems to me unlikely that javascript values held by rust could *ever* be sent transparently to another worker. The mechanism that rust apparently will use to implement transparent threading will be to use `SharedArrayBuffer` to share memory between multiple workers. Javascript provides a way for certain (serializable) objects to be shared with with other workers through `worker.postMessage()`, so Javascript has *some* story for sending javascript values to other threads, but only plain rust values that exist solely in the `SharedArrayBuffer` memory are send-able under this scheme. I've looked briefly through some of the wasm proposals like the interface types proposal, but I don't have a good sense if there's any proposed mechanism at all for interface types and threads to interact at all.
If that's true that's really unfortunate because it seems like any thread safe API shared by native and web is doomed to mismatch. This is even more unfortunate because many of the webgpu types in the draft standard are marked as 'Serializable', meaning that they *are* actually safe to send to another worker via `postMessage`, but there does not appear to be a planned way for rust to do this transparently.
I definitely could be misunderstanding the situation though and even if I am understanding it, the situation may have since changed. I also don't know the timing here, I don't know what the eventual timing of wasm32 threading support will be vs webgpu support and interface types support. *Right now* this PR is almost certainly sound, but there's definitely a possible future where it becomes unsound, and even maybe a possible future where it becomes unsound but then could later be made sound again.
Co-authored-by: kyren <kerriganw@gmail.com>
There are several things in this commit:
1) Add `Send` or `Send + Sync` bounds to most of the associated types in `Context`.
2) Force most of the handle types and future types returned by the web backend to be Send / Sync
3) Make `BufferReadMapping` and `BufferWriteMapping` `Send` again on native by
making the associated detail types implement `Send`.
295: Remove wasm-bindgen patches r=grovesNL a=rukai
A new release occurred with the required fixes, so we no longer need to patch it.
Co-authored-by: Rukai <rubickent@gmail.com>
281: The Context trait r=grovesNL a=kvark
The main motivation here is to avoid blocking the wgpu-core updates by `wgpu-native`. Instead, `wgpu-native` becomes a branch, and the dependency of `wgpu-rs` -> `wgpu-native` starts adhering to the contract/API of the standard webgpu-native headers.
The biggest change is the introduction of the Context trait. I recall us discussing 2 downsides to having this trait:
1. inconvenient for the users to include. This is a non-issue here, since it's private.
2. more code to maintain. This is less of an issue if we aim to have 3 backends.
What this gives in return is a well established contract with the backends. Unlike gfx-rs, the backend code is right here, a part of the crate, so the contract is only for internal use.
Fixes#156 : the "direct" implementation of it goes straight to wgpu-core. What this gives us is less overhead for command recording, since there is no longer an extra indirection on every command, and no heap allocation at the end of a render pass.
The downside of this PR is one extra `Arc` (with addref) per object.
This commit also has small improvements:
- consuming command buffers on submit (Fixes#267)
- Instance type
- proper call to destructors
- fallible `request_device`
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Main change here is the introduction of the Context trait.
The "direct" implementation of it goes straight to wgpu-core.
This commit also has small improvements:
- consuming command buffers on submit
- Instance type
- proper call to destructors
When looking into wgpu-rs as a replacement for WebGL I went to the
examples directory on GitHub to browse for a bit.
I wanted to see some of the examples at a glance without needing to
clone the repository.
This commit enables that by adding a README to each example with a
description of the example and screenshots / example output.
In a few cases the description is a bit redundant - but my hope is that
in the future we can improve all the READMEs.
Being a web API and thus very accessible, WebGPU could end up being many
people's first introduction to graphics programming so the lower we make
the barrier the better.
271: Improve docs for BindingType r=kvark a=HalfVoxel
I think everything should be correct.
The readonly flags seem obvious at face value, but I couldn't find anything in the specifications about them (other than some unrelated validation), so I didn't add any documentation for those fields.
Co-authored-by: Aron Granberg <aron.granberg@gmail.com>
262: Reverse srgb in hello-triangle r=kvark a=grovesNL
Reverse srgb support in hello-triangle (these were backwards by mistake)
Co-authored-by: Joshua Groves <josh@joshgroves.com>
264: Use opaque texels in mipmap example r=kvark a=grovesNL
This fixes rendering for the mipmap example in Nightly
Co-authored-by: Joshua Groves <josh@joshgroves.com>
