[canvaskit] Resize to exactly the requested dimensions

[harryterkelsen]

Adds a SurfaceResizeStrategy to Surface. The default option, onlyGrow, implements the current behavior of only re-allocating the Surface when the requested size is larger than the currently allocated Surface. This PR adds the option of SurfaceResizeStrategy.exact which always reallocates the Surface and resizes the underlying OffscreenCanvas. This options performs better in practice since having the OffScreenCanvas larger than the actual rendered size causes calls to createImageBitmap to be slower than if the OffscreenCanvas is exactly the size of the bitmap being created.

Fixes #162700

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[yjbanov]

LGTM to unblock the fix, but I sense there's a bigger underlying issue here.

According to the PR description:

having the OffScreenCanvas larger than the actual rendered size causes calls to createImageBitmap to be slower than if the OffscreenCanvas is exactly the size of the bitmap being created.

The extra cost in createImageBitmap must be due to memory copying. The returned ImageBitmap is not the same as the one owned by the OffscreenCanvas, but a new copy. So, at the end of every frame createImageBitmap leaves two copies, one owned by the OffscreenCanvas, and one owned by the copy created by createImageBitmap. If the window is being resized, all textures need to be discarded. So we'll have to discard two textures.

In contrast, transferImageBitmap does not create a copy, so at the end of the frame there's only one texture. When resizing, only that one texture needs to be discarded.

This is all assuming one target surface. I'm not sure how the math works out with platform views (or multi-view).

[yjbanov]

Where do we use onlyGrow?

[harryterkelsen]

I just got rid of the option and updated the tests to reflect the new resize behavior.

[harryterkelsen]

Re: #162708 (review)

I agree. I am investigating if we can switch to transferToImageBitmap here. This PR is a pre-requisite for enabling transferToImageBitmap since the underlying canvas needs to be exactly-sized for transferToImageBitmap

[yjbanov]