fix: backport patch for webaudio (#20924)

* fix: backport patch for webaudio

* chore: update patches
This commit is contained in:
Robo
2019-11-01 16:34:07 -07:00
committed by GitHub
parent 4c25b619a6
commit 1591e1320a
4 changed files with 37 additions and 2 deletions

View File

@@ -88,3 +88,4 @@ recreate_directmanipulationhelper_when_every_lrwhh_updateparent.patch
notify_directmanipulationeventhandler_when_directmanipulationhelper.patch
build_fix_when_building_with_enable_plugins_false.patch
mojo-js_change_how_js_sends_mojo_messages.patch
obtain_graph_process_lock_when_nullifying_the_buffer_in_reverb.patch

View File

@@ -6,7 +6,7 @@ Subject: fix: disabling compositor recycling
Compositor recycling is useful for Chrome because there can be many tabs and spinning up a compositor for each one would be costly. In practice, Chrome uses the parent compositor code path of browser_compositor_view_mac.mm; the NSView of each tab is detached when it's hidden and attached when it's shown. For Electron, there is no parent compositor, so we're forced into the "own compositor" code path, which seems to be non-optimal and pretty ruthless in terms of the release of resources. Electron has no real concept of multiple tabs per window, so it should be okay to disable this ruthless recycling altogether in Electron.
diff --git a/content/browser/renderer_host/render_widget_host_view_mac.mm b/content/browser/renderer_host/render_widget_host_view_mac.mm
index a1138408c0985efc1334c9a92f7e875680b69a4a..913c1c7cb541fd0f6f400beafbe9796b9cfcda96 100644
index a1138408c0985efc1334c9a92f7e875680b69a4a..48a71f0dba47fa34b537a2e955a1a1541659ece5 100644
--- a/content/browser/renderer_host/render_widget_host_view_mac.mm
+++ b/content/browser/renderer_host/render_widget_host_view_mac.mm
@@ -483,7 +483,12 @@

View File

@@ -1,7 +1,7 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Ken Rockot <rockot@google.com>
Date: Thu, 20 Jun 2019 01:37:22 +0000
Subject: [mojo-js] Change how JS sends Mojo messages
Subject: Change how JS sends Mojo messages
This changes how Mojo JS Blink bindings transmit messages produced from
JS code. Namely, instead of blindly stuffing the JS-provided message

View File

@@ -0,0 +1,34 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Hongchan Choi <hongchan@chromium.org>
Date: Wed, 30 Oct 2019 02:47:57 +0000
Subject: Obtain graph/process lock when nullifying the buffer in Reverb
When the buffer is set to `null` while there is an active buffer
within a reverb object, SetBuffer() function can prematurely
nullify the `reverb_` and `shared_buffer_` while it is still
being accessed by the rendering thread.
This CL adds two locks (graph lock and process lock) when the
buffer gets nullified to ensure the synchronization between
two threads.
Change-Id: I8f501b6a16b3c7e16db767e0b279a1a53d6eb290
Bug: 1019226
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1888103
Commit-Queue: Hongchan Choi <hongchan@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#710627}
diff --git a/third_party/blink/renderer/modules/webaudio/convolver_node.cc b/third_party/blink/renderer/modules/webaudio/convolver_node.cc
index 913134333ab48adc1be2a5614b2f26e309cb243e..158434d1d7450a176ed71d3f466b05fceaf54957 100644
--- a/third_party/blink/renderer/modules/webaudio/convolver_node.cc
+++ b/third_party/blink/renderer/modules/webaudio/convolver_node.cc
@@ -95,6 +95,8 @@ void ConvolverHandler::SetBuffer(AudioBuffer* buffer,
DCHECK(IsMainThread());
if (!buffer) {
+ BaseAudioContext::GraphAutoLocker context_locker(Context());
+ MutexLocker locker(process_lock_);
reverb_.reset();
shared_buffer_ = nullptr;
return;