refactor: egui sink

[bits0rcerer]

This PR aims to replace the custom canvas renderer by allocating/updating a texture managed by egui and displaying it as an egui image.

---

Bonus: our alpha values where always zero making the canvas theoretically always invisible. Now they are always 255.

[sbernauer]

Hi, thanks for this refactoring!
No opinions on the entire egui code, less lines are better I guess ^^

I tested this using

cargo r -- -s egui --egui-viewport 0x0,630x720 --egui-viewport 630x0,630x720

Previously both windows had a black background (which I was I expected).
Which this change the first window behaves as expected, but the second window behaves weird (I'm on KDE).

Initially it's transparent with some strange artefacts.

The following screenshot isn't correctly captured, but you can see the windows are... different.

When fluting an image it gets better, as the painting area is now painted correctly, but the section left and right of it stays this transparent-ish.

[bits0rcerer]

On Hyprland:

You are right. The main window has a dark gray background and any additional viewport has a black background.

I guess it depends on the compositor or desktop, how an area of a frame that did not receive any rendering will look like.

Fix is on its way..

[sbernauer]

Thanks for fixing this, looks good on my machine as well 👍

Looks like the new approach uses more CPU (compared to main). But I'm not knowledgeable of all this, so I trust you :)

As it changes the parser, I tried benchmarking the change but I had too much noise and I think this is fine, as we basically replace rgba & 0x00ff_ffff with rgba | 0xff00_0000, which should be the same in terms of performance.

One last question that came up.

[sbernauer]

Is this still needed? I tested it and from a quick glance it looks like it works fine without.
If needed could you please add a comment why we need this? (same above)

[bits0rcerer]

... aswell but CI fails without it.

https://github.com/sbernauer/breakwater/actions/runs/35897295535/job/107304289914#step:6:1880

[bits0rcerer]

Looks like the new approach uses more CPU (compared to main). But I'm not knowledgeable of all this, so I trust you :)

yeah, according to my test (run and look in btop)

• main: 19% cpu on idle
• using only egui facilities: 45% cpu on idle
• egui facilities with cutsom wgpu upload: saves one copy and loop through the canvas bytes and brings the performance back to: 20% cpu on idle

main currently uses custom rendering with the glow (opengl) backend. This PR uses the egui default backend wgpu (vulkan, metal, ...).
wgpu might be more desirable since it is more portable in terms compatibility with graphics apis.

On the other hand is currently real the performance regression worth the potential benefits of less code, more aligned with egui standards and newer graphics api?

What do you think?

[sbernauer]

When upgrading nightly on my machine I ran into the same recursion warning locally. I took the liberty of adding an explanatory comment generated by a friend 🙊

I have no opinion and knowledge on egui, as mentioned I trust you :)
I approved the PR, you can merge when you want.

[sbernauer]

Thanks!