Backport for X11 Display Server fixes on 3.2 branch.
1. Implement SAVE_TARGETS mechanism
Allows sending the clipboard content to the clipboard manager on exit to
keep the content when using a clipboard manager that doesn't
automatically makes a backup when copying.
MULTIPLE selection mechanism also had to be implemented, because in this
case, the clipboard manager might request multiple selection targets at
once.
Known use case: Ubuntu with XFCE4
2. Implement INCR mechanism
Allows pasting from x11 clipboard to receive data incrementally, which
is required when handling data size > 256KB.
Option in MeshInstance to enable software skinning, in order to test
against the current USE_SKELETON_SOFTWARE path which causes problems
with bad performance.
Co-authored-by: lawnjelly <lawnjelly@gmail.com>
1. _gen_unique_bone_name(Ref<GLTFState> state, const GLTFSkeletonIndex skel_i, const String &p_name) won't return an empty string.
2. String GLTFDocument::_sanitize_bone_name(const String &name) will keep Japanese characters. Like: "全ての親".
3. The sanitize function allows the bone name to be not just alphanumeric. The only required conditions are the ones in add_bone.
> ERR_FAIL_COND(p_name == "" || p_name.find(":") != -1 || p_name.find("/") != -1);
(cherry picked from commit 7b76f8783f)
The glTF 2.0 spec only makes `mimeType` mandatory for `bufferView` image data,
so the previous logic to handle URIs with base64-encoded images could fail if
`mimeType` is undefined.
The logic was documented and refactored to better handle the spec, notably:
- `uri` and `bufferView` are now mutually exclusive, and only the latter fails
if `mimeType` is undefined.
- `uri` with a file path will now respect the `mimeType` if defined, and thus
attempt loading the file with the specified format (even if its extension is
not the one expected for this format). So we can support bad extensions (PNG
data with `.jpg` extension) or custom ones (PNG data in `.img` file for
example).
- `uri` with base64 encoded data will infer MIME type from `data:image/png` or
`data:image/jpeg` if it was not documented in `mimeType` initially.
- `uri` with base64 encoded data, no `mimeType` and `application/octet-stream`
or `application/gltf-buffer` will fall back to trying both PNG and JPEG
loaders.
Fully fixes#33796 (and fixes up #42501).
(cherry picked from commit 2e99d0b26f)
See https://github.com/KhronosGroup/glTF/issues/944 for context on the
application/gltf-buffer MIME type.
The glTF 2.0 spec supports `image/jpeg` and `image/png` which can also be
base64-encoded in buffer URIs.
Fixes#33796.
(cherry picked from commit 34a50310ad)
No longer parse emscripten/emsdk config to detect emcc/node paths.
Use WhereIs to find "emcc" and "node", look for "node_modules" in "emcc"
path.
(cherry picked from commit 7998745237)
Measure the distance from the line against the rotated object, not the
rotated line, when obtaining the object's supports against a line.
(cherry picked from commit 7e44682c03)
The GDScript `load` mention is moved from the class `ResourceLoader`
description to the `ResourceLoader.load` method description instead,
where it is more likely to be found.
(cherry picked from commit a8404cf56c)
This should fix some of the audio stuttering issues when the HTML5
export is compiled with threads support.
The API should be ported to AudioWorklet to (hopefully) be perfect.
That though, cannot be backported to 3.2 due to extra restriction of
AudioWorklet (which only runs in SecureContext, and needs a polyfill for
Safari).
This allow the page to be considered a SecureContext if the address is
localhost (127.0.0.1/::1) and let Firefox (and future Chrome versions)
enable extra features needed for the HTML5 threaded export.