I don't see any reference to gzip/svgz supported in the nanosvg library,
and the handful of test gzip compressed svgz files I tried failed loading.
Also cleaning a couple missing includes in platform export code.
Fix incorrect context usage for off-screen drawing.
Remove kCGLCEMPEngine, which is causing flicker.
Disable window redraw during resize, when rendering in the separate thread.
Always build with the GUI subsystem.
Redirect stdout and stderr output to the parent process console.
Use CreateProcessW for blocking `execute` calls with piped stdout and stderr (prevent console windows for popping up when used with the GUI subsystem build, and have more consistent behavior with non-blocking calls).
Add `open_console` argument to the `execute` to open a new console window (for both blocking and non-blocking calls).
Remove `interface/editor/hide_console_window` editor setting.
Remove `Toggle System Console` menu option.
Remove `set_console_visible` and `is_console_visible` functions.
The code to populate the input data for WebAssembly was incorrectly
overriding values when multiple touches were present due to wrong
indexing.
(cherry picked from commit 470496d8d4)
Ensure better compatibility when emcc which may run some tools from
different paths (e.g. closure compiler).
This fixes externs include issues with modern emcc using the closure
compiler.
(cherry picked from commit eaedc92c61)
The "webgl/webgl2.h" include provides that function, but it's not
available in emscripten versions < 2.0.17 .
Since we need to support emscripten 1.39.9 (mono builds), this commit
adds a JS function in library_godot_display.js as a compatibility layer
for it, and implement glGetBufferSubData by funneling the call to that
function (so we don't have name collisions JS-side with recent emcc).
All those hacks are now moved to the platform directory instead of being
ifdefs inside the drivers implementations.
This actually makes sense(?), when running inside an iframe the active
element might be our canvas, while the iframe itself is not active in
the parent window. Since we consume the event, the iframe does not get
focused in Firefox (but does in Chromium-based browsers), so we must
always call focus to handle such occasions.
(cherry picked from commit 63e2db2499)
In some conditions the events might be generated even when the `gamepad`
object is not accessible due to Security Context requirements.
This commit adds a check to avoid firing the handler in those cases.
(cherry picked from commit 91dbc288cc)