Following a suggestion by Nasko in https://crrev.com/c/5867574, this
handles performance scenario shared memory completely in the blink and
components/performance_manager layers, getting rid of a shim through
content/ and chrome/.
This will unblock a followup CL to attach the browser-side
StructuredSharedMemory region to ProcessNode instead of
RenderProcessHost, which is blocked by the content/ shim accessing it
synchronously on the UI thread. The cost is an extra IPC roundtrip on
process startup.
Includes a partial revert of https://crrev.com/c/5867574 that returns
mojom::Renderer::TransferSharedMemoryRegions to TransferSharedLastForegroundTime.
Bug: 365586676
Change-Id: I681a3c941661ebba7c10b7abaf54aa5c4e430a9e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5949866
Commit-Queue: Joe Mason <joenotcharles@google.com>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Auto-Submit: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/main@{#1372300}
This CL adds 3 features to selectively disable/enable parts of the
memory pressure response in renderers:
"ForwardMemoryPressureToBlinkIsolates"
Controls whether memory pressure is forwarded to Blink isolates, which
has for effect to trigger a GC (critical) or start incremental marking
(moderate).
"ReleaseResourceStrongReferencesOnMemoryPressure"
Controls whether `blink::MemoryCache` and `blink::ResourceFetcher`
release their strong references to resources in response to memory
pressure. This affects whether previously used resources can be found
in the `blink::MemoryCache` in the future.
"ReleaseResourceDecodedDataOnMemoryPressure"
Controls whether `blink::Resource` releases its decoded data in
response to response to critical memory pressure. This affects
whether the data has to be decoded again if the resource is
reused in the future.
A previous experiment disabled *all* memory pressure clients in
renderers on desktop, with good impact on LCP but some memory
increase (go/finch50-no-memory-purge-in-renderers-desktop). The new
features will be used to assess the impact of important memory pressure
client on the LCP and memory metrics in isolation.
Bug: 40287434
Change-Id: I920389c3cadf3f6e82b6836e484adebf10ef90a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5913594
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Francois Pierre Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1366859}
In preparation of patches that will allow V4L2 decoding to work by
default on Linux.
The VA-API and V4L2 backends provide essenitaly the same output -
DMABufs in formats like NV12/P010 etc. - and face similar restrictions
e.g. GL driver features. It therefore makes sense to have the same media
switches and in fact some of them - most importantly
`VaapiVideoDecodeLinux` - already apply to V4L2.
Thus in order to reduce confusion and avoid code duplication, rename
some of the `Vaapi` swiches used in common code to `Accelerated` but
keep the `Linux` suffix, making it clearer to what they apply. Also
ensure they are used for both APIs the same way and update the
`vaapi.md`.
Finally, add `AcceleratedVideoDecodeLinuxZeroCopyGL` to the VA-API
documentation.
Bug: b:334110478
Change-Id: Iea58966d6ab94ce995defb1cf1099dd9ba9fae26
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5893615
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Fritz Koenig <frkoenig@chromium.org>
Commit-Queue: Fritz Koenig <frkoenig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363231}
In the previous CL, we programmatically enable the runtime feature for
prompt API in order to expose the JS handle to the self namespace, and
then copy the value to chrome.aiOriginTrial then reset it to
undefined.
The flow is now improved by getting the AIAssistantFactory directly
from the v8_context, with that, we can clear a lot of runtime features
check and unnecessary workaround code to make the implementation
cleaner.
Bug: 350642260
Change-Id: I71c99dddc7f6d0980a7819110f6d82f073c94aa2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5889515
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Commit-Queue: Mingyu Lei <leimy@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1360984}
* Renames TransferSharedLastForegroundTime to
TransferSharedMemoryRegions and uses it to transfer multiple region
handles. Also updates it to allow optional handles (the mojo typemap
will crash on invalid handles otherwise.)
* Adds functions to manage the browser side of the channel in
components/performance_manager.
* Adds accessors to ContentBrowserClient to return performance
scenario region handles. The default implementation returns invalid
handles, but ChromeContentBrowserClient gets the handles from
components/performance_manager.
* Adds a test for TransferSharedMemoryRegions.
Bug: 365586676
Change-Id: Ib0ff85e07459d768896ea571e357d687cb9e8243
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5867574
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Olivier Li <olivierli@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Joe Mason <joenotcharles@google.com>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/main@{#1359994}
This is a no-op on most platforms because kDisplayCritical and kCompositing are equivalent already, as desired after progress
on crbug.com/1329208
On Linux and Fuchsia: kDisplayCritical is not equivalent to kCompositing, so this CL introduces change in behavior.
On Linux, this CL aligns behavior to ChromeOS (ChromeOS is already
running kCompositing threads with the same priority as kDisplayCritical).
Population is generally too small to draw reliable conclusion from
an experiment, so it's more robust to align with ChromeOS.
On Fuchsia, we simply drop kCompositing.
Effectively, this CL brings all kCompositing threads (each process' main thread, compositor thread and IO thread) to a higher priority than it was before.
Bug: 1329208
Change-Id: I6331a3eacb2396117e20d833eb993a91eadd1d47
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4842549
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Owners-Override: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1344860}
Adds a cleaner interface to ReadOnlySharedMemoryRegion /
SharedMemoryMapping, which specifies the type that's stored in the
memory when the memory is mapped rather than on every access.
Converts some simple users of shared memory to use
StructuredSharedMemory.
Bug: 357945779
Change-Id: I27105cf7feb2136c14c7e345617f7e2284f15e0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5746992
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Reviewed-by: Yuzhu Shen <yzshen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1343748}
This is a reland of commit 7f04022ea0.
The original commit was reverted due to test failures in component
builds. These failures came in two flavors and this reland contains
fixes for both. They are:
1. Failures caused by the ProtectedMemory variable being initialized
not being in the proper memory address range. This is caused by the
memory segment code being defined in the .h file which means that
different DSOs can define different sections, and cross DSO calls
will show the memory in the wrong section. The fix is simply to
disable ProtectedMemory for component builds. Component builds are
never shipped so there is no value in supporting it for them.
2. The new get_{{feature.data_member_name}}() method added for
ProtectedMemory RuntimeEnabledFeatures, which is the method where the
static initializer was added, was defined in the include file instead
of the cc file. Thus the static initializer could be rerun in different DSOs. This resulted in the MojoJS runtime enabled feature
not necessarily getting the right value, causing tests that needed it
to be true to fail with MojoInterfaceInterceptor (because MojoJS
bindings weren't enabled). By moving the definition to the CC file,
this problem went away.
Original change's description:
> Make static initialization of base::ProtectedMemory objects required
>
> This change makes it so that static initialization of
> base::ProtectedMemory instances is always required, even if the type
> provides constant initialization. This achieved by removing the bool
> ConstructLazily template parameter from ProtectedMemory and related
> classes, and making the case where it's "true" the only case. Thus the
> lazy construction through base::ProtectedMemoryInitializer is required.
>
> This change is made in preparation of adding support for ProtectedMemory
> to non-windows platforms. On some platforms there is an issue with
> initializing the protected memory section to readonly at build/link
> time. To combat this, the required initialization of ProtectedMemory
> instances will be used to initialize the protected section to readonly
> at runtime.
>
> This change also updates previously added use cases of ProtectedMemory
> to add the now required initialization.
>
> Bug: 41495919
> Change-Id: Ice3d39caee28a3fc956d4d9ebca8c6f51d03ce1c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5668250
> Commit-Queue: Jeffrey Gour <jegour@microsoft.com>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1324440}
Bug: 41495919
Change-Id: Ic8d416e4278d1bddf892e0ba967999b3ba4e8f1b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5689823
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Jeffrey Gour <jegour@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1326184}
This reverts commit 7f04022ea0.
Reason for revert: suspected cause of 351926112
Original change's description:
> Make static initialization of base::ProtectedMemory objects required
>
> This change makes it so that static initialization of
> base::ProtectedMemory instances is always required, even if the type
> provides constant initialization. This achieved by removing the bool
> ConstructLazily template parameter from ProtectedMemory and related
> classes, and making the case where it's "true" the only case. Thus the
> lazy construction through base::ProtectedMemoryInitializer is required.
>
> This change is made in preparation of adding support for ProtectedMemory
> to non-windows platforms. On some platforms there is an issue with
> initializing the protected memory section to readonly at build/link
> time. To combat this, the required initialization of ProtectedMemory
> instances will be used to initialize the protected section to readonly
> at runtime.
>
> This change also updates previously added use cases of ProtectedMemory
> to add the now required initialization.
>
> Bug: 41495919
> Change-Id: Ice3d39caee28a3fc956d4d9ebca8c6f51d03ce1c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5668250
> Commit-Queue: Jeffrey Gour <jegour@microsoft.com>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1324440}
Bug: 41495919,351994238
Change-Id: I7c3956923253affc5dad294d03f05e1a3c39fd17
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5688694
Reviewed-by: Trevor Perrier <perrier@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@google.com>
Owners-Override: Trevor Perrier <perrier@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1324954}
This change makes it so that static initialization of
base::ProtectedMemory instances is always required, even if the type
provides constant initialization. This achieved by removing the bool
ConstructLazily template parameter from ProtectedMemory and related
classes, and making the case where it's "true" the only case. Thus the
lazy construction through base::ProtectedMemoryInitializer is required.
This change is made in preparation of adding support for ProtectedMemory
to non-windows platforms. On some platforms there is an issue with
initializing the protected memory section to readonly at build/link
time. To combat this, the required initialization of ProtectedMemory
instances will be used to initialize the protected section to readonly
at runtime.
This change also updates previously added use cases of ProtectedMemory
to add the now required initialization.
Bug: 41495919
Change-Id: Ice3d39caee28a3fc956d4d9ebca8c6f51d03ce1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5668250
Commit-Queue: Jeffrey Gour <jegour@microsoft.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1324440}
The GPU channel cannot be established when gpu_remote is disconnected.
Stop calling RequestNewLayerTreeFrameSink because it's going to fail
again and it will be stuck in a forever loop of retries. This makes the
processes unable to be killed after Chrome is closed.
Bug: 336164423
Change-Id: Ie7db1df5531e178b2d06063c10c23ded917217b8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5676887
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1323390}
This manager is only used to report metrics calculated in cc/metrics.
It's location in cc/trees predates the cc/metrics folder.
This change moves it, ahead of some follow ups to it's ownership, and
potential new UKMs
Bug: 334977830
Change-Id: Icbab339fe18ea4ef0f06b42b03f023125f4801a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5648501
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1322830}
This field is:
* Unsafe in presence of Oilpan (see https://crbug.com/40261265)
* Not actually used - there are no callers of
`AgentGroupScheduler::GetBrowserInterfaceBroker`. This method was
added in https://crrev.com/c/2677585 and AFAICT no callers have ever
been added later - for example this command finds no other commits:
`git log -S AgentSched -- content/browser/browser_interface_binders.cc`
Removing this field also helps to make progress on
https://crbug.com/41482945 - this field is related to 1 out of 5 callers
of `BrowserInterfaceBrokerProxy::Bind` and the linked bug requires
passing `ContextLifecycleNotifier` to `HeapMojoRemote`. I note that
`AgentGroupSchedulerImpl::BindInterfaceBroker` seems to be the only
caller of `BrowserInterfaceBrokerProxy::Bind` which doesn't have a 1:1
relationship with a `ContextLifecycleNotifier` (which IIUC roughly
corresponds to the `ExecutionContext`). The other callers are 1)
constructor of `WorkerGlobalScope`, 2) constructor of
`content::RenderFrameImpl`, 3)
`MojoBindingContext::SetMojoJSInterfaceBroker` (we ignore here
`GetEmptyBrowserInterfaceBroker` which doesn't actually need to bind an
actual mojo remote).
Fixed: 40261265
Bug: 41482945
Change-Id: Id07826bb008bea6157a30868a56ad05ad3bbc675
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5646657
Reviewed-by: Francois Pierre Doray <fdoray@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Auto-Submit: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1319775}
of a single boolean indicating if the process is backgrounded.
Currently a nop change as the enum is converted back to a single
boolean in the renderer, but it will be used in a later CL to
apply different interventions when a process is kUserVisible
versus kUserBlocking.
Bug: 41485666
Change-Id: Ide4130a1d7b9653ae434e0d0992d46f74fbb9e7f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5555305
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1314537}
Suppress unsafe buffer usage on a file-by-file basis. Out of
approximately 5850 .cc and .h files only roughly 160 files fail
compilation with the unsafe buffers warning.
Suppress only, by inserting boilerplate into affected files. Do not
re-write any code to work around the issues. Properly fixing each file
will be done in follow-up CLs.
//content/ is not removed from unsafe_bufers_paths.txt file and will be
also done as a follow-up, so it makes potential reverts simpler.
Bug: 342213636
Change-Id: I4a936e63dea95a78951f7bfae6d5487708ae3c0b
AX-Relnotes: n/a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5608913
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1312393}
It will support automatic ".BestEffort" suffixing in renderers for
metrics that rely on timing.
It uses shared memory to share read-only std::atomic<TimeTicks> state
between RenderProcessHostImpl and the renderer.
"HangWatcher.IsThreadHung.RendererProcess.*" will be the first metric to
test this out. There was a recent "regression" caused to it by a
mix-shift when shipping more aggressive backgrounding of best-effort
renderers on Mac, recovering from that is how we test that this works.
Local chrome://histograms test: https://snipboard.io/KjNzMa.jpg
Bug: 334983411
Change-Id: I78259ca47514059a74fb1b672192e90b24551e31
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5459762
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Reviewed-by: Olivier Li <olivierli@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1311669}
This was generated by replacing " NOTREACHED()" with
" NOTREACHED_IN_MIGRATION()" and running git cl format.
This prepares for making NOTREACHED() [[noreturn]] alongside
NotReachedIsFatal migration of existing inventory.
Bug: 40580068
Change-Id: I3b48b89911ac5e9ffcb211622992f917f8f9e8d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5539619
Auto-Submit: Peter Boström <pbos@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1301096}
It turns out there are still a few places that construct base::Features
directly, or use otherwise creative ways to construct a base::Feature.
Migrate them all to using the macro in preparation for implementing a
stricter check.
Bug: 40239032
Change-Id: I2a9e96a65bdffa909ccad7c94a1b22dd925239fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5507544
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Owners-Override: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1295486}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Iee14d10d544e9f0ec046117cc4ec8a55c427adc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5469947
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290838}
We suspect this is causing renderer OOMs, so the BatterySaverModeRenderTuning experiment was disabled. Removing this from battery saver renderer tuning will allow us to re-start the experiment.
Bug: 328805793
Change-Id: I2e3181cfe0d5071b5f412d850137142ef600ab1d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5444734
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Anthony Vallée-Dubois <anthonyvd@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1287370}
content/browser
The changes of this CL are made using the following script.
```
target_directory="content"
replace_string_in_files() {
old_string="$1"
new_string="$2"
find "$target_directory" -type d \( -path "$target_directory/browser" -prune \) -o \( -name "*.cc" -o -name "*.h" \) -exec sed -i '' "s/$old_string/$new_string/g" {} +
}
delete_include() {
find "$target_directory" -type d \( -path "$target_directory/browser" -prune \) -o \( -name "*.h" -o -name "*.cc" \) -print0 | while IFS= read -r -d '' file; do
grep -v '#include "base/strings/string_piece.h"' "$file" > "$file.tmp" && mv "$file.tmp" "$file"
done
}
add_include() {
find "$target_directory" -type d \( -path "$target_directory/browser" -prune \) -o \( -name "*.h" -o -name "*.cc" \) -print0 | while IFS= read -r -d '' file; do
local include_added=false
local tempfile=$(mktemp)
if grep -qE 'std::(string|u16string)_view' "$file"; then
while IFS= read -r line; do
echo "$line" >> "$tempfile"
if [[ $line =~ ^\s*#include ]]; then
if ! $include_added; then
echo "#include <string_view>" >> "$tempfile"
include_added=true
fi
fi
done < "$file"
mv "$tempfile" "$file"
if $include_added; then
echo "Added #include <string_view> after the first include line in $file"
else
echo "No include line found in $file"
fi
else
echo "std::string_view not found in $file"
fi
done
}
replace_string_in_files "base::StringPiece16" "std::u16string_view"
replace_string_in_files "base::StringPiece" "std::string_view"
delete_include
add_include
```
Replaced base::StringPiece16 with std::u16string_view
Replaced base::StringPiece with std::string_view
Removed header "base/strings/string_piece.h"
Added header "<string_view>" where applicable
Bug: 40506050
Change-Id: Ia6d2fd65a16e1a3db59532c085652fbb45dc6abc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5401324
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1285651}
Remove RasterInterfaceInVideoResourceUpdater killswitch which is
currently present only for Android. It was enabled for Android
in M123 which is in stable for quite some time.
Also, clean up surrounding code in VideoResourceUpdater that is GL
specific and remove ScopedTexture.
Bug: 332564976, 40276184
Change-Id: I92265198033b75ea18eaf58b3a1f99f2856156d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5420132
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Saifuddin Hitawala <hitawala@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1283205}
This CL cleans up of the UpdateSystemColorInfo() pipeline by removing
the `forced_colors` and `is_dark_mode` param. Originally, this pipeline
was designed to inform Blink of the system color info states changes.
However, with system colors now being retrieved from color providers
(CL:5322440) and forced colors now existing as a Web setting
(CL:5368321), these params have become redundant and therefore can be
safely removed.
Bug: 1231644, 41489514
Change-Id: Ic5320cde57947523daea5b8ac481a276bdda1611
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5381326
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Sam Davis Omekara <samomekarajr@microsoft.com>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1278739}
This CL begins the cleaning up of the UpdateSystemColorInfo() pipeline
by removing the colors parameter. Originally, this pipeline was
designed to enable the LayoutTheme retrieve system colors from the
NativeTheme. However, as system colors are now retrieved through color
providers in Blink, the colors parameter has become redundant and
therefore can be removed.
Next steps will involve removing the `is_dark_mode` and `forced_colors`
parameters. This will be carried out following the ongoing efforts to
make forced colors state in Blink a web setting, as initiated in
CL:5324688.
Bug: 1430181, 40779801
Change-Id: Id14c501faff3b47488a5ca43d639dc72afd6acb3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5341963
Commit-Queue: Sam Davis Omekara <samomekarajr@microsoft.com>
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1274229}
I believe the reason for the crashes is that when
shrinking the ring buffer size (AdjustForBackground), I
wasn't adjusting global_empty_slot_span_ring_index. This
meant that if global_empty_slot_span_ring_index was >
kMinFreeableSpans, a slot-span could end up being assigned
an index beyond the ring buffer size. This is because
SlotSpanMetadata::RegisterEmpty increments
global_empty_slot_span_ring_index based on the current index and
global_empty_slot_span_ring_size:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/third_party/angle/third_party/dawn/third_party/angle/third_party/dawn/third_party/partition_alloc/src/partition_alloc/partition_page.cc;l=115-116;drc=4b0447a323de1a925d2b08127e256ef735d73fc3
Also, in this version the features are all disabled. I'll enable
via field trial.
Original description:
Calling to madvise/mprotect is expensive on macs. This patch aims
to reduce the number of such calls. It adds the following:
. Increases empty cache index bits by 8.
. If RegisterEmpty() is called and the slot span was already
registered, don't do anything. This is in hopes of avoiding
churn if a slot-span is reused a bunch.
. Increases max_empty_slot_spans_dirty_bytes_shift by a factor of 2.
. Adds feature for that makes blink's partition for buffers use the
large empty slot span ring.
Bug: 329199197
Change-Id: I819ba2ba82bbed83cba40d7561f21f4aa19ff088
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5362719
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Benoit Lize <lizeb@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1272345}
This reverts commit 660e70eeac.
Reason for revert: This seems to have caused some crashes. See https://crbug.com/328875414
Original change's description:
> pa: couple of tweaks based on Speedometer
>
> Calling to madvise/mprotect is expensive on macs. This patch aims
> to reduce the number of such calls. It adds the following:
> . Increases empty cache index bits by 8.
> . If RegisterEmpty() is called and the slot span was already
> registered, don't do anything. This is in hopes of avoiding
> churn if a slot-span is reused a bunch.
> . Increases max_empty_slot_spans_dirty_bytes_shift by a factor of 2.
> . Adds feature for that makes blink's partition for buffers use the
> large empty slot span ring.
>
> Change-Id: I6bde3c62e1e9edd280f649ec71eb6d1bf04eb644
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5181724
> Reviewed-by: Scott Violet <sky@chromium.org>
> Commit-Queue: Scott Violet <sky@chromium.org>
> Reviewed-by: Benoit Lize <lizeb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1270352}
Bug: 328875414
Change-Id: Iba537e69f2f64b35c3352368e36a762d3eea2d36
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5360238
Commit-Queue: Scott Violet <sky@chromium.org>
Owners-Override: Fred Shih <ffred@chromium.org>
Reviewed-by: Benoit Lize <lizeb@chromium.org>
Reviewed-by: Fred Shih <ffred@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1271054}
Calling to madvise/mprotect is expensive on macs. This patch aims
to reduce the number of such calls. It adds the following:
. Increases empty cache index bits by 8.
. If RegisterEmpty() is called and the slot span was already
registered, don't do anything. This is in hopes of avoiding
churn if a slot-span is reused a bunch.
. Increases max_empty_slot_spans_dirty_bytes_shift by a factor of 2.
. Adds feature for that makes blink's partition for buffers use the
large empty slot span ring.
Change-Id: I6bde3c62e1e9edd280f649ec71eb6d1bf04eb644
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5181724
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Reviewed-by: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1270352}
This is a reland of commit 73317c46c9.
The issue was that we were tried to paint with null color providers.
This occurred when a Page is created through the non-standard route
(i.e. not associated with a web view). This issue is now addressed in
CL:5230300 where we plumb the color maps required to create color
providers via WebView::Create down to page creation. For places where
the color maps are unavailable such as non-ordinary pages or tests we
fall back to a default set of color maps. This ensures that every Page
created has valid color provider instances.
This change also adds a unit test to ensure all Pages created (ordinary
and non-ordinary) have non-null color provider instances.
Original change's description:
Paint controls using Page's color provider
This CL is a follow up on CL:5042390 and CL:5046572, where we plumbed
the page's color providers and added color provider support for tests.
This CL uses the plumbed provider to paint by passing it as an argument
to the NativeTheme Paint function in WebThemeEngineDefault::Paint.
This CL cleans up the previous pipeline which originally saw color
provider instances exist in Blink::WebThemeEngineDefault. This clean up
also saw us change the ExecutePageBroadcastMethod call to
ExecutePageBroadcastMethodForAllPages in
WebContentsImpl::OnColorProviderChanged.
Additionally, this CL moves the logic of determining the color scheme
based on the accent color to the ThemePainterDefault and ensures the
correct color scheme is calculated before painting.
Bug: 1430181
Change-Id: Ib5b38436d8872f36bd42f61febb9f7018f3f1d26
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5282903
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Sam Davis Omekara <samomekarajr@microsoft.com>
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1263607}
