Also:
* changed `[b]true[/b]` to `[code]true[/code]`
* use `[i]` for mathematical constant "e"
* use `[b]` for button text & menu item text
* improve markups about "tap1" and "tap2" in AudioEffectDelay
Removing the Android toolchain saves 14 GiB, which gives us more room
for growth and to avoid running into out-of-space errors in the Linux
sanitizers + debug symbols builds.
Related to #79919, though the caches were just one part of the problem,
the real issue is that our Linux sanitizers builds take 12 GiB, and
adding godot-cpp on top with 2 GiB leaves only a few GiB left for the
cache itself.
The previous implementation for signals mouse_entered and mouse_exited
had shortcomings that relate to focused windows and pressed mouse buttons.
For example a Control can be hovered by mouse, even if it is occluded by
an embedded window.
This patch changes the behavior, so that Control and Viewport send
their mouse-enter/exit-notifications based solely on mouse position,
visible area, and input restrictions and not on which window has
focus or which mouse buttons are pressed. This implicitly also
changes when the mouse_entered and mouse_exited signals are sent.
This functionality can not be implemented as a part of
Viewport::_gui_input_event, because of its interplay with Windows and
because Viewport::_gui_input_event is based on input and not on
visibility.
Currently, GDScripts who are only loaded through `ResourceLoader::load()`,
like Autoloads, do not have a pathway to announce there is an error in their
code. This contributes to significant confusion in error projects when
autoloads are involved. At least partially closes#78230.
1. Validation layers on Windows were complaining w/
VUID-VkSwapchainCreateInfoKHR-surface-01270 that we were not calling
vkGetPhysicalDeviceSurfaceSupportKHR before vkCreateSwapchainKHR.
2. Godot was only calling vkGetPhysicalDeviceSurfaceSupportKHR at
startup, but it should be doing this for every window w/ a new surface
it wants to create, not just the first one.
- In practice this will likely not make a difference. If
vkGetPhysicalDeviceSurfaceSupportKHR returns false after initialization,
there's nothing we can do about it and it is likely because something
else went terribly wrong, which is why the error message is worded like
that.
- This is mostly to shut up validation layers. Though technically,
the layers are right.
3. Do not call vkGetPhysicalDeviceSurfaceSupportKHR on queues we don't
even plan on ever using. We don't know how drivers will react to that
(e.g. they may preemptetively allocate resources to support presentation
on exotic queues, instead of just saying no). Just behave like every
other Vulkan app out there.
