Add some docs about lowspec rendering (#5091)

# Objective

- When experimenting with rendering on lowspec machines I've run into some non-obvious things (huge thanks [superdump](https://github.com/superdump), [alice-i-cecile](https://github.com/alice-i-cecile), [mockersf](https://github.com/mockersf) and others for help) and so volunteered to document them.
- Is a follow-up of https://discordapp.com/channels/691052431525675048/989137552919375902

## Solution

- I added docs about necessity of `ANGLE` to use `Backends::GL` on Windows.
- Also documented why `prepare_windows` can be long to execute and some causes.

crates/bevy_render/src/settings.rs

@@ -16,6 +16,12 @@ pub enum WgpuSettingsPriority {
 /// Provides configuration for renderer initialization. Use [`RenderDevice::features`](crate::renderer::RenderDevice::features),
 /// [`RenderDevice::limits`](crate::renderer::RenderDevice::limits), and the [`WgpuAdapterInfo`](crate::render_resource::WgpuAdapterInfo)
 /// resource to get runtime information about the actual adapter, backend, features, and limits.
+/// NOTE: [`Backends::DX12`](Backends::DX12), [`Backends::METAL`](Backends::METAL), and
+/// [`Backends::VULKAN`](Backends::VULKAN) are enabled by default for non-web and the best choice
+/// is automatically selected. Web using the `webgl` feature uses [`Backends::GL`](Backends::GL).
+/// NOTE: If you want to use [`Backends::GL`](Backends::GL) in a native app on Windows, you must
+/// use [`ANGLE`](https://github.com/gfx-rs/wgpu#angle). This is because wgpu requires EGL to
+/// create a GL context without a window and only ANGLE supports that.
 #[derive(Clone)]
 pub struct WgpuSettings {
     pub device_label: Option<Cow<'static, str>>,

crates/bevy_render/src/view/window.rs

@@ -121,6 +121,27 @@ pub struct WindowSurfaces {
     configured_windows: HashSet<WindowId>,
 }
 
+/// Creates and (re)configures window surfaces, and obtains a swapchain texture for rendering.
+///
+/// NOTE: `get_current_texture` in `prepare_windows` can take a long time if the GPU workload is
+/// the performance bottleneck. This can be seen in profiles as multiple prepare-stage systems all
+/// taking an unusually long time to complete, and all finishing at about the same time as the
+/// `prepare_windows` system. Improvements in bevy are planned to avoid this happening when it
+/// should not but it will still happen as it is easy for a user to create a large GPU workload
+/// relative to the GPU performance and/or CPU workload.
+/// This can be caused by many reasons, but several of them are:
+/// - GPU workload is more than your current GPU can manage
+/// - Error / performance bug in your custom shaders
+/// - wgpu was unable to detect a proper GPU hardware-accelerated device given the chosen
+///   [`Backends`](crate::settings::Backends), [`WgpuLimits`](crate::settings::WgpuLimits),
+///   and/or [`WgpuFeatures`](crate::settings::WgpuFeatures). For example, on Windows currently
+///   `DirectX 11` is not supported by wgpu 0.12 and so if your GPU/drivers do not support Vulkan,
+///   it may be that a software renderer called "Microsoft Basic Render Driver" using `DirectX 12`
+///   will be chosen and performance will be very poor. This is visible in a log message that is
+///   output during renderer initialization. Future versions of wgpu will support `DirectX 11`, but
+///   another alternative is to try to use [`ANGLE`](https://github.com/gfx-rs/wgpu#angle) and
+///   [`Backends::GL`](crate::settings::Backends::GL) if your GPU/drivers support `OpenGL 4.3` / `OpenGL ES 3.0` or
+///   later.
 pub fn prepare_windows(
     // By accessing a NonSend resource, we tell the scheduler to put this system on the main thread,
     // which is necessary for some OS s