Text / AA rendering a bit off

[alextechcc]

Hey, just want to start by saying that I feel like ECS with immediate mode rendering as this crate does it I think is like - an absolutely fantastic idea - and I really appreciate your responsiveness in all the issues here - and I'd love to start helping out if I can.

It seems either AA or hinting or blending/color conversion or the texel alignment is a bit off - at least with stock settings. Not exactly sure where to look.

Take a look at this image, the S in particular:

It looks a bit more bold and uneven on bevy side. And taking a look at the pixels and editing the levels a bit to make it more obvious:

I have been trying to experiment with the shader/clip rect/blending to fix this but have been unsuccessful so far. In some cases, not the image I've shown but with some text - it appears that the bevy version renders one pixel downwards compared to eframe, so I tried offsetting -0.5, -0.5 but that did not work. I also have ensured that bevy is using GL for consistency. It seems like color blending is correct, I have tried a 0 to 255 SRGB gradient and the values are identical when screencapped.

[alextechcc]

Perhaps it's missing this change:
emilk/egui@f46926a

Kinda out of my wheelhouse here, but it seems that doing everything in gamma space and then converting to linear works:

diff --git a/src/render/egui.wgsl b/src/render/egui.wgsl
index 5b4b4e3..b162935 100644
--- a/src/render/egui.wgsl
+++ b/src/render/egui.wgsl
@@ -62,14 +62,8 @@ fn fs_main(in: VertexOutput) -> @location(0) vec4<f32> {
     let image_sampler = image_sampler[offset];
     #endif
 
-    let texture_color_linear = textureSample(image_texture, image_sampler, in.uv);
-    // We un-premultiply Egui-managed textures on CPU, because Bevy doesn't premultiply it's own images, so here we pre
-multiply everything.
-    let texture_color_linear_premultiplied = vec4<f32>(texture_color_linear.rgb * texture_color_linear.a, texture_color
_linear.a);
-    let texture_color_gamma_premultiplied = gamma_from_linear_rgba(texture_color_linear_premultiplied);
-
-    // Quoting the Egui's glsl shader:
-    // "We multiply the colors in gamma space, because that's the only way to get text to look right."
-    let color_gamma = texture_color_gamma_premultiplied * in.color;
-
-    return vec4<f32>(linear_from_gamma_rgb(color_gamma.rgb), color_gamma.a);
+    let tex_gamma = textureSample(image_texture, image_sampler, in.uv);
+    let tex_gamma_premul = vec4<f32>(tex_gamma.rgb * tex_gamma.a, tex_gamma.a);
+    let out_gamma = tex_gamma_premul * in.color;
+    return vec4<f32>(linear_from_gamma_rgb(out_gamma.rgb), out_gamma.a);
 }

I don't currently understand why changing the TextureFormat in the bevy image side doesn't do anything.

[vladbat00]

Hi! Thanks for the kind words and the issue report.

Yeah, the fix makes sense, and I believe it's a shader version that we had before. The only problem with it is that Bevy has its own textures unpremultiplied, so this will make custom texture look weird.

If we apply this fix, someone else will definitely report an issue with custom textures color, so the question is which compromise we want to make. Maybe better text rendering has indeed a higher priority.

Ideally, it would be nice to figure out how to load bevy textures as pre-multiplied just for Egui, or maybe we could pass a boolean indicating whether a texture is pre-multiplied or not with a push constant, so we could branch to the correct variant of the shader code based on that.

[alextechcc]

Looks like there's this issue:
bevyengine/bevy#14711

And this PR:
bevyengine/bevy#20545

[vladbat00]

Oh nice. This is interesting, even though a bit different. If Bevy gets support for premultiplied alpha render targets, that means that we should encourage users to always use a separate camera for Egui and/or even disable context auto-creation. That'll definitely be a breaking change, since bevy_egui users relied on auto-created contexts for a single existing camera in the past, but that'll probably be a good change.

[WenSimEHRP]

Hi, this problem is even worse with Chinese characters
(also on the right side the k in km is not handled correctly)

In comparaison to this, which is rendered correctly: