Correct some typos/out-of-sync in docs (#669)

* Typo ad bug fixes to tut 1

* tutorial 2

Includes a bug fix for a bug I ran into. This is probably common on Macs with Retina displays, which have a default resolution of 3024 x 1964 for the 14"

* small typo

* Update README.md

Author: mud2monarch

docs/beginner/tutorial1-window/README.md

@@ -78,7 +78,7 @@ impl State {
 // ...
 ```
 
-There's not much going on here, but once we start using WGPU will start filling this up pretty quick. Most of the methods on this struct are place holders, though in `render()` we ask the window to draw another frame as soon as possible as winit only draws one frame unless the window is resized or we request it to draw another one.
+There's not much going on here, but once we start using, we WGPU will start filling this up pretty quick. Most of the methods on this struct are place holders, though in `render()` we ask the window to draw another frame as soon as possible as winit only draws one frame unless the window is resized or we request it to draw another one.
 
 Now that we have our `State` struct, we need to tell winit how to use it. We'll create an `App` struct for this.
 
@@ -135,7 +135,7 @@ impl ApplicationHandler<State> for App {
         #[cfg(not(target_arch = "wasm32"))]
         {
             // If we are not on web we can use pollster to
-            // await the 
+            // await the window creation
             self.state = Some(pollster::block_on(State::new(window)).unwrap());
         }
 
@@ -180,7 +180,7 @@ The `resumed` method seems like it does a lot, but it only does a few things:
 - It defines attributes about the window including some web specific stuff.
 - We use those attributes to create the window.
 - We create a future that creates our `State` struct
-- On native we use pollster to get await the future
+- On native we use `pollster` to await the future
 - On web we run the future asynchronously which sends the results to the `user_event` function
 
 The `user_event` function just serves as a landing point for our `State` future. `resumed` isn't async so we need to offload the future and send the results somewhere.
@@ -284,7 +284,7 @@ Now, all we need are some more dependencies that are specific to running in WASM
 ```toml
 # This should go in the Cargo.toml in the root directory
 
-# tThis is not required for WASM as wasm-opt should take care of this.
+# This is not required for WASM as wasm-opt should take care of this.
 # It can also interfere with WASM builds so feel free to leave it out.
 # It helps if you are wanting to build native binaries, as it helps reduce
 # the size of the executable, and make it harder to reverse engineer.
@@ -341,7 +341,7 @@ Now you can build a wgpu application with just wasm-bindgen, but I ran into some
 
 To get around this shortcoming and to make the lives of everyone reading this easier, I opted to add [wasm-pack](https://drager.github.io/wasm-pack/) to the mix. Wasm-pack handles installing the correct version of wasm-bindgen for you, and it supports building for different types of web targets as well: browser, NodeJS, and bundlers such as webpack.
 
-To use wasm-pack, first, you need to [install it](https://drager.github.io/wasm-pack/).
+To use wasm-pack, first, you need to [install it](https://wasm-bindgen.github.io/wasm-pack/installer/).
 
 Once you've done that, we can use it to build our crate. If you only have one crate in your project, you can just use `wasm-pack build`. If you're using a workspace, you'll have to specify what crate you want to build. Imagine your crate is a directory called `game`. You would then use:
 

docs/beginner/tutorial2-surface/README.md

@@ -239,6 +239,15 @@ pub fn resize(&mut self, width: u32, height: u32) {
 
 This is where we configure the `surface`. We need the surface to be configured before we can do anything with it. We set the `is_surface_configured` flag to true here and we'll check it in the `render()` function.
 
+Note that the max supported dimension in WebGL is 2048 px. If you have a larger display, you must cap the height and width, e.g.:
+
+```rust
+if width > 0 && height > 0 {
+  let max = 2048;
+  self.config.width = width.min(max);
+  self.config.height = height.min(max);
+```
+
 ## handle_key()
 
 This is where we'll handle keyboard events. Currently just want to exit the app when the escape key is pressed. We'll do some other stuff later.

docs/beginner/tutorial3-pipeline/README.md

@@ -167,9 +167,9 @@ pub struct State {
     queue: wgpu::Queue,
     config: wgpu::SurfaceConfiguration,
     is_surface_configured: bool,
+    window: Arc<Window>,
     // NEW!
     render_pipeline: wgpu::RenderPipeline,
-    window: Arc<Window>,
 }
 ```
 
@@ -311,6 +311,7 @@ If you run your program now, it'll take a little longer to start, but it will st
             Some(wgpu::RenderPassColorAttachment {
                 view: &view,
                 resolve_target: None,
+                depth_slice: None,
                 ops: wgpu::Operations {
                     load: wgpu::LoadOp::Clear(
                         wgpu::Color {
@@ -325,6 +326,9 @@ If you run your program now, it'll take a little longer to start, but it will st
             })
         ],
         depth_stencil_attachment: None,
+        occlusion_query_set: None,
+        timestamp_writes: None,
+        multiview_mask: None,
     });
 
     // NEW!

docs/compute/introduction/readme.md

@@ -43,13 +43,13 @@ said, not all algorithms benefit from leveraging this compute power.
 I can't possibly make a comprehensive list of all the things you could use a GPU for,
 but here are some rules of thumb:
 
-- Tasks that can be easily parrallelized. GPUs don't like switching tasks, so if you
+- Tasks that can be easily parallelized. GPUs don't like switching tasks, so if you
 need the computation to use data from previous operations, compute shaders are likely
 to be slower than a CPU based approach. If each operation can excute without any
 knowledge of other operations, you can get a lot out of the GPU.
-- You already have the data on the GPU. If your working with texture or model data
-It can often be faster to process it with a compute shader rather than copying the data
-to the CPU, modifying it, than shipping that back to the GPU.
+- You already have the data on the GPU. If you're working with texture or model data,
+it can often be faster to process it with a compute shader rather than copying the data
+to the CPU, modifying it, then shipping that back to the GPU.
 - You have a massive amount of data. At some point the size of your data starts to outweigh
 the setup time and complexity of using a compute pipeline. You'll still need to tailor
 your approach to the data and processing you need to do.