It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Add "clang-format off" comment cause the code after formatting looks weird
c.f.
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8808670914002799937/+/u/test:_format_and_dart_test/stdout?format=raw

cc @flar

1. The height of the image is almost one pixel larger than bounds at the beginning

In Rasterize, the height of dest_rect (bounds) is 1890, but its hex value is 0x1.d88002p+10, so the height of the image calculated by SkScalarCeilToInt(dest_rect.height()) is 1891

2. Round-off error caused by different dy in matrix

The cause for the issue is that there is a slight difference in the height of bounds calculated by the method RasterCacheUtil::GetDeviceBounds in the RasterCache::Rasterize and RasterCacheResult::draw.

And bounds is calculated by logical_rect and matrix, their logical_rect is the same.
Here is its decimal value and hex value via std::hexfloat
The following is the logical_rect:

But m[5] (dy) in their matrix is ​​different, and it's what caused the round-off error.

RasterCache::Rasterize

The following is the matrix used in RasterCache::Rasterize：

The bounds calculated by logical_rect and matrix in RasterCache::Rasterize:

image height is: 1891

The result of subtracting the image height from the bounds height is:

-0.999878 ( -0x1.fffp-1 )

RasterCacheResult::draw

The following is the matrix used in RasterCacheResult::draw：

The bounds calculated by logical_rect and matrix in RasterCacheResult::draw:

image height is: 1891

The result of subtracting the image height from the bounds height is:

-1.00012 ( -0x1.0008p+0 )

@flar Although the cause has been found, I still don't know how to fix the math. So I set epsilon to 1/512 first. One thing to note here is that the test below also needs to use epsilon instead of 0. Otherwise it will crash too.

image_->dimensions().width() - bounds.width() > -epsilon

Please let me know if you have any thoughts :)

@flar Although the cause has been found, I still don't know how to fix the math. So I set epsilon to 1/512 first. One thing to note here is that the test below also needs to use epsilon instead of 0. Otherwise it will crash too.

image_->dimensions().width() - bounds.width() > -epsilon

Please let me know if you have any thoughts :)

Yes, I see now that the issue is related to changing floating point resolution as you translate an object. At one offset two values might differ by just smaller than an integer and at another offset they will be greater, depending on how many bits of mantissa were lost.

The only way I could see to prevent the problem would be to use a "coverage aware ceil" operation on the bounds. Basically, avoid padding the bounds if they are just slightly larger than a pixel. So, something like "ceil(width - epsilon)". No use allocating a pixel for something that will not see any non-transparent pixels in practice.

test-exempt: asserts are tests.