When a FlowContainer had a TextureRect child using any of the EXPAND_FIT_* expand modes, it could crash when changing the FlowContainer's minimum size, or that of its children. This was due to the TextureRect resizing in FlowContainer::_resort, updating its minimum size, and triggering another _resort. If the TextureRect's minimum size changed in a way that caused any of the FlowContainer's children to be put on a different line, it could repeatedly cause _resort to be called again, moving the children back and forth between the old and new lines.
This change is for FlowContainer::_resort to give a warning for TextureRects with EXPAND_FIT_* expand modes when multiple lines are used, and just keep the TextureRect size the same in that case. This is similar to the check added to AspectRatioContainer in godotengine#73396, but attempting to still support it in FlowContainer when possible. In the case where the TextureRect is forced to stay the same size, there may be some overlap between the FlowContainer's children, but should no longer crash.
The issue was that Node3DEditorViewport was using the render server's BVH to filter out nodes,
which is not correct for gizmos that have no renderable components,
or have collision triangles that exceed the bounds of their renderable components.
`EDSCALE` scaling was applied even though it shouldn't be, which led
to pixelated thumbnails due to double scaling. For reference,
AudioStream previews don't use `EDSCALE` and look fine at any editor
scale (the editor itself already scales the thumbnail requests).
This switches to 64-bit integers in select locations of the Image
class, so that image resolutions of 16384×16384 (used by
lightmap texture arrays) can be used properly. Values that are larger
should also work.
VRAM compression is also supported, although most VRAM-compressed
formats are limited to individual slices of 16384×16384. WebP
is limited to 16383×16383 due to format limitations.
The `-j` flag is only settable via the command line, which makes it hard
to configure when running builds from places like VS, where the flag isn't
easily exposed or configurable.
This lets users configure the number of jobs to be used by default if `-j`
isn't specified, instead of always defaulting to number of cores - 1.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
This is about not letting the resource format loader set the error code directly on the task anymore. Instead, it's stored locally and assigned only when it is right to do so.
Otherwise, other tasks may see an error code in the current one before it's state having transitioned to errored. While this, besides the technically true data race, may not be a problem in practice, it causes surprising situations during debugging as it breaks assumptions.
