
Here are some miscellaneous tips for optimizing WebGPU for speed.

## Avoid creating too many resources each frame
If you call `engine.enableEffect()`, make sure to pass a `DrawWrapper` to it, not an `Effect`. Otherwise, some WebGPU resources will be created each frame.

To check that you are not creating unnecessary resources, once your application is running and has stabilized, meaning you did not create new objects in the last frame, check `engine.countersLastFrame` and make sure `numEnableEffects` is 0. `numEnableEffects` is greater than 0 when you call `engine.enableEffect()` with an `Effect` instead of a `DrawWrapper`. Only `numEnableDrawWrapper` should be nonzero.

## Optimize post processes
If you set the `textureSampler` property manually in an `onApply` observer, set `externalTextureSamplerBinding = true` on the post-process to improve performance.

If possible, do not set the `reusable` parameter of the `PostProcess` constructor to `true`. Otherwise, there will be continuous swapping between the two textures used as the render target of the post-process, which is especially bad in non-compatibility mode because the cached render bundle will be recreated each frame.



This section explains how WebGPU has been implemented in Babylon.js. It may be useful for users who want to contribute to the engine or simply understand what is going on under the hood.


**Snapshot rendering** is a new rendering mode available starting with Babylon.js v5.0. Only WebGPU supports it: activating this mode in WebGL has no effect.

## Description
The snapshot rendering (SR) feature improves performance in some specific scenarios described below.

It works by recording the draw calls during one frame and by replaying this recording for all subsequent frames. So, the scene should be mostly static for this mode to work as expected. Note that this mode can be enabled or disabled whenever you want. So, if at some point something must change in the scene that is not supported by SR, you can disable the mode, apply the changes and re-enable SR afterwards.

Note that the performance improvement is on the JavaScript side only: GPU performance will be more or less the same with or without SR enabled, though you could still see some small GPU performance improvements depending on the browser.

The performance improvements can be quite large, especially when using fast SR mode (see below for explanations of the SR modes). Here are some figures collected with the first PG listed in the **Examples** section:

| WebGL 2 version | SR - Standard mode | SR - Fast mode | 
|-------------|---------------|-----------|
| ![WebGL2 ](/img/resources/snapshot_rendering/webl2_comparison.webp) | ![Standard mode](/img/resources/snapshot_rendering/sr_standard.webp!241x247) | ![Fast mode](/img/resources/snapshot_rendering/sr_fast.webp!245x243) |

## Enabling snapshot rendering mode
The snapshot rendering mode is enabled by setting:
```javascript
engine.snapshotRendering = true;
```
When doing this, the next frame will be recorded (and of course also displayed as usual!) and the recorded snapshot will be replayed in all subsequent frames until you either disable the mode or use `engine.snapshotRenderingReset()`. If calling the latter, a new snapshot will be created the next frame that will replace the current snapshot.

Calling `engine.snapshotRenderingReset()` is how you apply changes that are not supported by the current SR mode (see the available modes in the next section): apply your changes and call this function. It destroys the current snapshot and instructs the system to create a new one by recording the draw calls of the next frame, which will contain your changes. In effect, it is the same as doing `engine.snapshotRendering = false; engine.snapshotRendering = true;`. The first assignment stops and destroys the current snapshot, and the second asks the system to record the draw calls when rendering the next frame. Of course, for this to work, your changes should be in effect by the next frame. If, for example, you import a new mesh, it will probably take more than a frame to be added to the scene. So, you should call `engine.snapshotRenderingReset()` once you know the next frame will render the scene with the new state.

## Standard and Fast modes
There are two different modes available when SR is enabled:
* Standard mode (`Constants.SNAPSHOTRENDERING_STANDARD`). In this mode, the uniform buffers are still updated, so some dynamic behavior is still supported: you can update some parameters of a material, for example, and it will work.
* Fast mode (`Constants.SNAPSHOTRENDERING_FAST`). In this mode, only the scene uniform buffer is updated automatically by the system (meaning moving the camera works as expected). You can still update the uniform buffers of meshes "by hand", so moving/rotating meshes are also supported (see examples below).

Whatever the mode, as the draw calls of a given frame are recorded and replayed for all subsequent frames, adding or removing meshes won't work. You will need to disable the SR mode if you want to add/remove meshes and re-enable it afterwards.

## Caveats

### Always set `alwaysSelectAsActiveMesh` to `true`
Given how SR works, you will probably always want to set `alwaysSelectAsActiveMesh = true` for all your meshes because if this property is `false` (the default value) and the mesh is not displayed when recording the snapshot, no draw calls will be recorded for it. This means that if you later move the camera in a way that should make the mesh visible, it still will not be visible.

### Statistics in the Inspector
In fast SR mode, most of the regular JavaScript code is skipped, so the statistics displayed by the Inspector in the **COUNT** section will not be accurate: all the **Active XXX** counters, as well as **Total vertices**, will stay at 0.

### When to use
It's hard to list everything that will work/won't work depending on the mode, so the easiest way to use this new feature is to enable it and see if everything works as expected once enabled (try first fast mode, then standard mode). As explained above, if you need to update something at some point in time and the current SR mode can't handle it, you can always disable SR, apply the changes and re-enable SR.

eCommerce sites may greatly benefit from this feature because the scene is normally quite small, with everything visible on screen. Also, there generally is not much dynamic behavior, and when something needs to be updated it is usually a "one-shot" update, so either calling `snapshotRenderingReset` or temporarily disabling the feature should work.

### Enable the snapshot rendering mode at the right time
Make sure everything in your scene is ready to be rendered on the next frame after you set `engine.snapshotRendering = true`! Once you set `snapshotRendering` to `true`, the next frame is recorded and replayed afterwards. If some textures, for example, are not ready at that time, the mesh will not be rendered in the recorded frame and therefore will never be visible. You should probably always set `engine.snapshotRendering = true` inside a `scene.executeWhenReady(...)` callback.

## Examples
Here's a PG that demonstrates using the snapshot rendering feature: <Playground image="/img/playgroundsAndNMEs/pg-SYQW69-1092.webp" id="#SYQW69#1354" engine="webgpu" title="Snapshot rendering" description="Demonstrate how to use the snapshot rendering modes"/>

You can choose to disable or enable standard / fast SR mode. Depending on the mode, you will see the JavaScript time it takes to render a frame (**Frame total**) and the virtual fps (the fps you would have if there were no GPU rendering / the fps were not capped by the browser - it is simply `1000/Frame total`).

In fast mode, animating light / updating the bias would not work for the reasons explained above. When you update:
* the **bias**, the PG calls `engine.snapshotRenderingReset()` so that the bias is taken into account for the next frame and the snapshot is recreated at that time too
* the **Animate light** checkbox, the PG switches to standard SR mode until you uncheck the box. Moving the light does work in standard SR mode: if it did not, we would have switched to SR disabled mode instead.

Note also that in fast SR mode you must handle updates to the sky position yourself because the uniform buffers are not updated by the system, except for the scene buffer. See [The SnapshotRenderingHelper class](#the-snapshotrenderinghelper-class) section for more details.

Here's another PG using the glow layer: <Playground id="#LRFB2D#182" engine="webgpu" title="Snapshot rendering with glow layer" description="Demonstrate how to use the snapshot rendering standard mode with glow layer"/>

This PG is using the standard SR mode because the fast mode does not work (try to set the fast mode and see for yourself - however, see next section for a way to make it work). Also, when a resize kicks in, we need to disable the SR mode and re-enable it only when the glow layer had time to recreate its internal texture with the new size. That's why we use a `setTimeout(..., 1)` to re-enable the SR mode.

## The SnapshotRenderingHelper class
Fast SR mode is the most interesting mode because your scene can be handled several orders of magnitude faster than with SR disabled, or even than when using standard SR mode.

To simplify the use of fast SR mode, we have created a [SnapshotRenderingHelper](https://doc.babylonjs.com/typedoc/classes/babylon.snapshotrenderinghelper) class to help you work with this mode. This class is available as of Babylon.js version 7.32.0.

To use it, create an instance of the class and call `enableSnapshotRendering()` after you have loaded or created your scene:
```typescript
const sr = new BABYLON.SnapshotRenderingHelper(scene);
...
// make sure your scene is loaded/created
...
sr.enableSnapshotRendering();
```

Call `updateMesh()` to update a mesh when its position/rotation/scaling property has changed.

If you create a layer (glow, highlight), call `updateMeshesForEffectLayer()` for that layer to make it compatible with fast SR mode.

If you create or add new meshes later on, call `fixMeshes()` to make sure they are compatible with fast SR mode:

* their `ignoreCameraMaxZ` property will be set to `false`, as this feature is not compatible with fast SR mode
* the maximum number of influencers of morph target managers will be set to a fixed value (that you can define through the `options` parameter of the `SnapshotRenderingHelper` constructor). This is needed to make sure morphs work in fast SR mode

<br/>Thanks to this class, we can handle a number of dynamic cases very simply:
* Updating position/rotation/scaling/visibility properties of meshes: <Playground id="#7YW416#11" engine="webgpu" title="Update mesh matrix in fast SR mode with snapshot helper class" description="Demonstrates how to update the position/rotation/scaling/visibility properties of a mesh in fast snapshot rendering mode with snapshot helper class" image="/img/playgroundsAndNMEs/pg-7YW416-3.webp"/>
* Using the glow layer: <Playground id="#LRFB2D#852" engine="webgpu" title="Use glow layer in fast SR mode with snapshot helper class" description="Demonstrates how to make the glow layer work in fast snapshot rendering mode with snapshot helper class" image="/img/playgroundsAndNMEs/pg-LRFB2D-218.webp"/>
* Animating bones: <Playground id="#WGZLGJ#10670" engine="webgpu" title="Use bones in fast SR mode with snapshot helper class" description="Demonstrates how to make bones work in fast snapshot rendering mode with snapshot helper class" image="/img/playgroundsAndNMEs/pg-WGZLGJ-4072.webp"/>
* Using a default skybox: <Playground id="#WGZLGJ#10671" engine="webgpu" title="Use default skybox in fast SR mode with snapshot helper class" description="Demonstrates how to make default skyboxes work in fast snapshot rendering mode with snapshot helper class" image="/img/playgroundsAndNMEs/pg-WGZLGJ-10606.webp"/>




WebGPU Miscellaneous Optimizations

Avoid creating too many resources each frame

Optimize post processes