GLES: on EGL, respect the user requesting a non-sRGB surface format

[liquidev]

Checklist

• Run cargo clippy.
• Run RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown if applicable.
  • Not applicable in this case since this is a native backend change.
• Add change to CHANGELOG.md. See simple instructions inside file.

Description
What used to happen was that sRGB was used whether you requested it or not. This PR fixes that and now passing in a non-sRGB texture format in SurfaceConfiguration will result in a non-sRGB surface being created.

Testing
To test this, compare a surface configured with the first available non-sRGB format to a surface configured with the first available sRGB format on the OpenGL/EGL backend:

fn configure_surface(&self, size: PhysicalSize<u32>) {
   let format = self
      .capabilities // wgpu::SurfaceCapabilities
      .formats
      .iter()
      .find(|format| !format.is_srgb()) // <-- Remove `!` to test the sRGB case
      .copied()
      .unwrap_or(self.capabilities.formats[0]);
   let surface_configuration = wgpu::SurfaceConfiguration {
      usage: wgpu::TextureUsages::RENDER_ATTACHMENT,
      format,
      width: size.width,
      height: size.height,
      present_mode: wgpu::PresentMode::AutoVsync,
      alpha_mode: wgpu::CompositeAlphaMode::Opaque,
      view_formats: vec![],
   };
   self.surface.configure(&self.device, &surface_configuration);
}

(First time contribution here, not sure if/how I should write an integration test for this?)

[Wumpf]

Thanks for fixing this!
Haven't tested it myself but looks good to me. Regarding automated testing, I think we can let it slide for this one - it's usually super tricky to read the actual surface back (which is why all tests that need to reason about render output read back a different target) making this fairly hard to test.

[torokati44]

Would it be possible to backport this fix to the 0.16 series please?
The greater ecosystem is still in the process of migrating over to 0.17.0 so we can't switch yet.

[Wumpf]

Any particular project that's blocking you? Historically we haven't done much backporting after a major release, but I don't think it's off the table :)

[torokati44]

I have since pushed this to v0.16 in my fork, and switched to that in the project where this was important.

Any particular project that's blocking you?

One of them was egui - granted, only for the desktop build, and I asked for the backport because of the Android build, so this is not that crucial. And the 0.17 switch is in master already, just not released.

The more important is naga_oil, which is used in all builds. There is a working PR with the switch to 0.17, which is waiting for a Bevy release to be merged.