- Properly read from the circular buffer (fixes#13173)
- Fix requested frame count check (it was failing when requested frequency was higher than source frequency)
In order to support the combined use of GLFW and WebGPU, GLFW
should not assign anything to the Emscripten modules context variable.
GLFW supports not creating any OpenGL context using the windows
attribute GLFW_CLIENT_API.
As requested at #12646
There are some blockers to add it to Gentoo properly:
* Incompatibility with stable LLVM and binaryen
* Dependency on npm which we can't yet handle cleanly
When strings are converted without using TextDecoder, an off-by-on error
causes an out-of-bounds memory read. Fix this by turning the while loop
into a for loop with an appropriate bounds check.
Test the marshalling with null-terminated and non-null-terminated
strings. The code is based on the test for UTF32.
In https://github.com/emscripten-core/emscripten/blob/master/src/library_exceptions.js,
the uncaught exception count is incremented and decremented exactly once during
__cxa_throw and __cxa_begin_catch respectively (as the ABI says it should be). This
however doesn't get re-incremented in the event of a rethrow, so anything that happens
between the first catch and the second catch (eg. destructors) receive the decremented
value.
In LLVM the count is incremented again in __cxa_rethrow, which curiously the ABI does
not ask us to do, but seems to be the behaviour we expect. Perhaps the ABI assumes
that rethrow calls throw under the hood. This PR brings us closer to that, and in alignment
with LLVM.
The testcase added here now emits the same correct output as a native build, which
it did not before this PR.
#12409 introduced a bug.
The PR was merged with the assumption that != on Date objects compares the
date values just like the greater than operator does. Unfortunately, this checks
for object reference equivalence and will always evaluate to false in this case
since each timestamp is a separate Date object.
This is a followup of #5519 and #5655 since they were closed.
It is possible to implement emscripten::vecFromJSArray more efficiently for numeric
arrays by using the optimized TypedArray.prototype.set function.
The main issue with this method is that it will silently fail(or succeed) if elements of
the array or not numbers, as it does not do any type checking but instead works as
if it called the javascript Number() function for each element. (See ToNumber for more
details)
So instead of simply updating vecFromJSArray to use this new implementation and
break code (since there's no typechecking anymore) I added a new
convertJSArrayToNumberVector (name subject to change) and improved performance
a tiny bit for vecFromJSArray by:
* Taking the val parameter by const reference instead of copy
* Reserving the storage of the vector
Imports the implementation of many NEON intrinsics in as a single header from the SIMDe project (https://github.com/simd-everywhere/simde) as well as documentation on how to use them. Also adds a script to update the NEON header with the latest upstream changes from SIMDe.
Fixes#6551
Removes the static_asserts that check if the type for a LightTypeID is_polymorphic.
AFAICT, LightTypeID works fine with polymorphic types, and provides the same
identity guarantees as when RTTI is enabled. Adds a test asserting such code
compiles and runs correctly.
I'm still not clear why this restriction was in place - it may have been necessary
in previous impelmentations, or perhaps with previous versions of LLVM/Clang.
However, as far as I can tell, it's not necessary now and only limits options
around doing non-RTTI builds with emscripten. Attempting to create a testcase
showing why the restrictions makes sense fails (see discussion in PR).
When calling PATH.basename on paths with a trailing slash (i.e. /emscripten/),
an empty string will be returned instead of "emscripten". This leads to errors
with rmdir and rename called on paths with a trailing slash.
This PR looks to first normalize the path, leading to at most one trailing slash
remaining in the path, and then removing that trailing slash.
Fixes#11897
The WebIDL.Parser() was calling yacc which is in
debug mode by default, causing it to create parser.out.
Furthermore, the pickle filename 'WebIDLGrammar.pkl'
was being passed in, which results in yacc writing its
tables to that filename.
Fixes#10986
Fixes#11503
This allocates memory in the heap for the relevant data structures,
and JS just refers to those places. This helps make exception handling
thread-safe (however, still not 100%, see comments in the code).
This also fixes issues with the old code mixing up catch contexts
with exceptions. The new code separates out the two properly. As
a result this fixes#11776
Further improvements after this may include rewriting this to C
so it's entirely in wasm, which could make it 100% thread-safe and
also work in standalone mode etc. (However, the new wasm
exception handling will have those properties already.)
* Add WEBGL_multi_draw extension
* use var instead of let
* Fix as suggested
* Add WebGL extension tests for WebGL_multi_draw
* python formatting
* Fix multi draw tests and related bugs
* Skip test when extension is not supported
* Fix comment text
* remove unnecessary else intent
* refactor block position
* Address some of jukka's comment
* Fix function signature
* Fix function signature suffix back to WEBGL
* Fix extension enabling schema
* Address review comments
* Fix accidentally committed change of test_browser
* python style fix
An exception was thrown when loading the data JS loader script,
due to window being unavailable in a Worker.
Tested on recent versions of Chrome, Firefox and Safari.
Fixes#11673
The webgl port of glGetShaderiv(..., GL_INFO_LOG_LENGTH)
incorrectly returned 1 when there was no information log. The GLES 2
standard says that it should return 0 in this case. This change will make
it correctly return 0.