commit | ed5e03d4440ad99e918f71a7319efa1cebdb4eca | [log] [tgz] |
---|---|---|
author | Colin Blundell <blundell@chromium.org> | Tue Sep 24 15:23:10 2024 |
committer | Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Sep 24 15:23:10 2024 |
tree | c992595f94a2f34c451e576524ad604db544fb2c | |
parent | 473b5ed58f95d142232dda64dfd8dcb4b65cec74 [diff] |
[Blink] Make FallbackToSoftwareOnFailedTextureAlloc more precise As the test is structured now, it looks like what is being verified is that the call to `NewImageSnapshot()` causes a downgrade from GPU rasterization to CPU rasterization. In fact, that is not what is happening at all. Instead, it is the call to `DrawSomething()` that causes the switch: * Before this call there is no CanvasResourceProvider and so the host defaults to the preference that has been set * This call causes a CanvasResourceProvider to be created. It is not possible to create a valid CanvasResourceProviderSharedImage without a GrDirectContext, and so the created CRP is unaccelerated. Hence, after this call the host will be using CPU rasterization. This CL updates the test to make this flow precise, which will aid in porting it to be a test on CanvasRenderingContext2D while being clear about the functionality actually being tested. I also removed an irrelevant expectation on CanvasResourceHost::IsResourceValid() being true. This expectation returns true here because no CC layer has been created, which doesn't have anything to do with the rest of what the test is setting up and checking. Bug: 40280152 Change-Id: I59f10ff318fe7f5566e1d4b7a7421d8ded37c14d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5881979 Reviewed-by: Jean-Philippe Gravel <jpgravel@chromium.org> Commit-Queue: Colin Blundell <blundell@chromium.org> Cr-Commit-Position: refs/heads/main@{#1359371}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
To check out the source code locally, don't use git clone
! Instead, follow the instructions on how to get the code.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure.
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.
If you found a bug, please file it at https://crbug.com/new.