commit ed5e03d4440ad99e918f71a7319efa1cebdb4eca
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

[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}