[Impeller] new blur: refactored math and fixed expanded padding size

[gaaclarke]

This refactors the math so that it makes it easier to conditionally add padding. That optimization was removed for now since it wasn't quite working satisfactorily yet.

This also fixes the math used to expand the coverage hint. There is no visual test for it since it would only ever result in wasteful expansion that would show up in the benchmarks.

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 and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

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

[gaaclarke]

Here is the stats as this pr stands now:

    "average_vsync_transitions_missed": 5.6770428015564205,
    "90th_percentile_vsync_transitions_missed": 6.0,
    "99th_percentile_vsync_transitions_missed": 6.0,
    "average_vsync_frame_lag": 0.0,
    "90th_percentile_vsync_frame_lag": 0.0,
    "99th_percentile_vsync_frame_lag": 0.0,
    "average_layer_cache_count": 0.0,
    "90th_percentile_layer_cache_count": 0.0,
    "99th_percentile_layer_cache_count": 0.0,
    "average_frame_request_pending_latency": 16637.95840266223,
    "90th_percentile_frame_request_pending_latency": 16726.0,
    "99th_percentile_frame_request_pending_latency": 16788.0,
    "worst_layer_cache_count": 0.0,
    "average_layer_cache_memory": 0.0,
    "90th_percentile_layer_cache_memory": 0.0,
    "99th_percentile_layer_cache_memory": 0.0,
    "worst_layer_cache_memory": 0.0,
    "average_picture_cache_count": 0.0,
    "90th_percentile_picture_cache_count": 0.0,
    "99th_percentile_picture_cache_count": 0.0,
    "worst_picture_cache_count": 0.0,
    "average_picture_cache_memory": 0.0,
    "90th_percentile_picture_cache_memory": 0.0,
    "99th_percentile_picture_cache_memory": 0.0,
    "worst_picture_cache_memory": 0.0,
    "total_ui_gc_time": 2.8120000000000003,
    "30hz_frame_percentage": 0.0,
    "60hz_frame_percentage": 100.0,
    "80hz_frame_percentage": 0.0,
    "90hz_frame_percentage": 0.0,
    "120hz_frame_percentage": 0.0,
    "illegal_refresh_rate_frame_count": 0,
    "average_gpu_frame_time": 83.81782945736434,
    "90th_percentile_gpu_frame_time": 125.0,
    "99th_percentile_gpu_frame_time": 125.0,
    "worst_gpu_frame_time": 125.0,
    "average_cpu_usage": 114.68125052083332,
    "90th_percentile_cpu_usage": 122.700001,
    "99th_percentile_cpu_usage": 124.599999,
    "average_gpu_usage": 100.0,
    "90th_percentile_gpu_usage": 100.0,
    "99th_percentile_gpu_usage": 100.0,
    "average_memory_usage": 76.1376953125,
    "90th_percentile_memory_usage": 81.25,
    "99th_percentile_memory_usage": 83.546875
  },

This may be a slight improvement over previous readings ("average_gpu_frame_time": 87.70)

[bdero]

A couple of things come to mind while thinking about this:

1. Did you mean to compare against the expanded coverage hint instead? At the end of the downsample pass, we need to have enough content in the downsample pass to cover sampling from the entire expanded coverage area area for the full area of the expanded coverage hint.
2. Should this check be flipped? Like if the expanded_coverage_hint is equal to or a subset of the input_snapshot_coverage, then I suppose that would indicate that the snapshot rendered content into a big enough square that we don't need to worry about creating more with the proper tiling mode.

[gaaclarke]

I don't think so, the input_snapshot_coverage is incorporating the expanded coverage hint.

This is basically saying: I requested an expanded_coverage_hint and the snapshot you gave me for that doesn't contain all of the area of the coverage_hint. Therefore, some part of the halo will be visible and we'll add padding.

[gaaclarke]

Check out the test, that should make this clear. The coverage_hint is saying we are going to render a small portion of the image, so there is no need to add the halo gutter.

[bdero]

Ah, I actually missed the not operator in front of the Contains check here.

I still think this isn't quite working for all cases. I made an interactive playground (will push a PR for it) to demonstrate an issue with Decal tiling:

Screen.Recording.2023-12-20.at.5.08.59.AM.mov

The color jumping is explained by flutter/flutter#140193 (comment) and isn't the focus of the video. The main problem is that the edge of the blurred image turns opaque when the clip becomes contained by the input snapshot coverage.

[bdero]

(Made a PR for the interactive toy here: #49283)

[gaaclarke]

Ahh right, the coverage_hint has to be inside of the snapshot image coverage while accounting for the blur radius. I'll fix that although I wonder if that will make this optimization hardly applicable.

[gaaclarke]

I fixed the problem, but there is a jump in the rendering because of the downsampling issue. It also catches way less cases now because it isn't cutting off the padding when hitting the edge of the input. I'm going to keep all the refactors and land it as a refactor since I have PRs that depend on this. I can circle back.

I also ran into a fun Rect floating point bug =( flutter/flutter#140464

[bdero]

LGTM