egui_kittest 0.33 bypasses TextureOptions set by user

[MichaelGrupp]

Describe the bug

Since #7602 egui_kittest uses "predictable" texture sampling, which basically means that a manual linear filtering is used always, regardless of the TextureOptions. Shader code:

egui/crates/egui-wgpu/src/egui.wgsl

Lines 101 to 106 in 96470fa

	fn sample_texture(in: VertexOutput) -> vec4<f32> {
	if r_locals.predictable_texture_filtering == 0 {
	// Hardware filtering: fast, but varies across GPUs and drivers.
	return textureSample(r_tex_color, r_tex_sampler, in.tex_coord);
	} else {
	// Manual bilinear filtering with four taps at pixel centers using textureLoad

To Reproduce

Create a snapshot that contains a texture with TextureOptions::NEAREST, or with mixed options like

egui::TextureOptions {
    magnification: egui::TextureFilter::Nearest,
    minification: egui::TextureFilter::Linear,
    ..Default::default()
}

The texture will always have linearly interpolated texels with egui_kittest 0.33, and there seems to be no (obvious) way to turn that off.

Expected behavior

Would be nice to find a solution that allows nearest filtering in snapshots again.

Some ideas:

• textures are rendered with the requested texture filter type
  • ...but the predictable linear filtering should be kept, I guess
  • i.e. add also a manual Nearest filter to sample_texture in the shader code (not sure tho if it's possible to distinguish the cases there?)
• allow to disable the predictable behavior, e.g. in the harness options?

Screenshots

I found this while trying to migrate my project to egui 0.33 (MichaelGrupp/maps#105).

There I have a snapshot test that renders a tiny 5x5 pixel image as a large texture (to check rendering accuracy, and to check that Nearest filtering is used by default for magnifications, as this is desired in my application).

That's a pretty obvious error, but there are probably also other cases where this might cause unforeseen results.

egui 0.32	egui 0.33

Outside of testing, egui 0.33 works just fine as it's using the normal texture sampling.

Additional context

[emilk]

Good catch.

Before we spend too much time on this, let's make sure the whole predictable_texture_filtering is carrying its own weight. I didn't have time to properly test how much difference it does when comparing the output of different GPUs before I merged it