Fix and update Wayland scale handling

[YaLTeR]

Right now Tracy uses the maximum scale across all advertised outputs. If you're on a mixed-DPI system, you get 2x-scaled Tracy on your 1x-scaled monitor, which looks a bit blurry.

This PR fixes and updates the scale handling:

1. Changes Tracy to use the maximum scale across all outputs that the Tracy surface is actually displaying on, rather than all advertised outputs.
   • This necessitated adding a way to dynamically change the scale, since the surface can move between differently-scaled outputs.
   • Behavior with TRACY_DPI_SCALE set was preserved.
2. With wl_compositor v6, instead of the output scale guesswork, Tracy will use the scale explicitly requested for the surface by the compositor. The compositor can generally make a better decision here, and this also makes the scale correct right from the very first frame drawn by Tracy, if the compositor sends the preferred scale before the surface is mapped.

I tested it on:

• sway for wl_compositor < 6
• mutter for wl_compositor < 6
• my own compositor for wl_compositor = 6 which sends the preferred scale right away

There's still an issue that Tracy doesn't ensure that its buffer is divisible by the scale, which results in it getting killed if that happens. However, it was already present before this PR, so nothing really changes here.

[wolfpld]

Good changes, but I don't want to touch the current Wayland code. I have a better implementation that splits things up and makes things more readable that I was going to backport to Tracy, but it's still in the queue. I'll try to get to it soon, and this new implementation would be open to improvements. I already handle 1. correctly, but 2. still needs to be implemented (but it's already easier to handle multiple versions of the protocol). Sounds good?

[YaLTeR]

Alright, sure.

[wolfpld]

See https://github.com/wolfpld/tracy/tree/wayland-refactor.

The dynamic DPI works comically bad for me in KDE, but that's just enough for me at this moment.

[YaLTeR]

When moving between differently scaled outputs during trace loading, I sometimes hit this crash:

Tracy-debug: ../../../imgui/imgui.cpp:7831: void ImGui::SetCurrentFont(ImFont*): Assertion `font && font->IsLoaded()' failed.

Thread 1 "Tracy-debug" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44        return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff72d28a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff72808ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff72688ff in __GI_abort () at abort.c:79
#4  0x00007ffff726881b in __assert_fail_base (fmt=0x7ffff73e7af8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0xbbd40c "font && font->IsLoaded()", file=file@entry=0xbba246 "../../../imgui/imgui.cpp", line=line@entry=7831, function=function@entry=0xbbd3e8 "void ImGui::SetCurrentFont(ImFont*)") at assert.c:92
#5  0x00007ffff7278c57 in __assert_fail (assertion=0xbbd40c "font && font->IsLoaded()", file=0xbba246 "../../../imgui/imgui.cpp", line=7831, function=0xbbd3e8 "void ImGui::SetCurrentFont(ImFont*)") at assert.c:101
#6  0x00000000004268aa in ImGui::SetCurrentFont (font=0x1abb130) at ../../../imgui/imgui.cpp:7831
#7  0x0000000000426a12 in ImGui::PushFont (font=0x1abb130) at ../../../imgui/imgui.cpp:7849
#8  0x00000000007bc676 in tracy::View::DrawNotificationArea (this=0x7ffff00008e0) at ../../../server/TracyView_NotificationArea.cpp:257
#9  0x0000000000647b52 in tracy::View::DrawImpl (this=0x7ffff00008e0) at ../../../server/TracyView.cpp:1024
#10 0x00000000006456d7 in tracy::View::Draw (this=0x7ffff00008e0) at ../../../server/TracyView.cpp:652
#11 0x0000000000a58b8a in DrawContents () at ../../src/main.cpp:978
#12 0x0000000000a60a07 in std::__invoke_impl<void, void (*&)()> (__f=@0x1852740: 0xa56b03 <DrawContents()>) at /usr/include/c++/13/bits/invoke.h:61
#13 0x0000000000a5fbf0 in std::__invoke_r<void, void (*&)()> (__fn=@0x1852740: 0xa56b03 <DrawContents()>) at /usr/include/c++/13/bits/invoke.h:111
#14 0x0000000000a5e705 in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/13/bits/std_function.h:290
#15 0x00000000005cb398 in std::function<void ()>::operator()() const (this=0x1852740 <(anonymous namespace)::s_redraw>) at /usr/include/c++/13/bits/std_function.h:591
#16 0x0000000000a63ee9 in Backend::Run (this=0x7fffffffdb30) at ../../src/BackendWayland.cpp:71
#17 0x0000000000a55abb in main (argc=1, argv=0x7fffffffe138) at ../../src/main.cpp:326

[wolfpld]

It makes no sense to put this off any longer, while I'm constantly not in the mood to deal with whatever it is that is wrong with my branch.

[YaLTeR]

Thanks