Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

@liyuqian
Copy link
Contributor

Previously, it's sending the wrong ctm: the one before the translation.
It's important because canvas.translate is applying the offset to the
matrix using preTranslate, so the fractional scale factor could turn an
integral offset into a final (postTranslate) fractional offset.

After the revision, we no longer fail the assertion that the image rect
should exactly matches the bounds.

I didn't find any case in our code where we used the wrong ctm for
raster cache key. Therefore, we have to find another unit test that
could surface the failed check in the 1st gen Nexus7.

Previously, it's sending the wrong ctm: the one before the translation.
It's important because canvas.translate is applying the offset to the
matrix using preTranslate, so the fractional scale factor could turn an
integral offset into a final (postTranslate) fractional offset.

After the revision, we no longer fail the assertion that the image rect
should exactly matches the bounds.

I didn't find any case in our code where we used the wrong ctm for
raster cache key. Therefore, we have to find another unit test that
could surface the failed check in the 1st gen Nexus7.

cache.Get(*picture, ctm).draw(canvas);
#ifndef SUPPORT_FRACTIONAL_TRANSLATION
canvas.setMatrix(RasterCache::GetIntegralTransCTM(canvas.getTotalMatrix()));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line defeats the purpose of this test as stated in the comment above it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't snap, we'd fail the integral translation assert instead of of bounds assert above. This test tries to reproduce the bounds assert.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the current way that we use the raster cache, this whole test doesn't make sense then.

It will be useful when we introduce "cache at 0,0 - render at any fractional translation" later, though. In that case we will see output size differences of up to +1 from the cached image.

liyuqian added a commit to liyuqian/engine that referenced this pull request Apr 17, 2020
This avoids the possible matrix mismatch between RasterCache::Get and
RasterCacheResult::draw. See
flutter#17790 for an example that tries
to fix an earlier mismatch.
liyuqian added a commit to liyuqian/engine that referenced this pull request Apr 21, 2020
This avoids the possible matrix mismatch between RasterCache::Get and
RasterCacheResult::draw. See
flutter#17790 for an example that tries
to fix an earlier mismatch.
@liyuqian liyuqian closed this Apr 21, 2020
liyuqian added a commit to liyuqian/engine that referenced this pull request Apr 22, 2020
This avoids the possible matrix mismatch between RasterCache::Get and
RasterCacheResult::draw. See
flutter#17790 for an example that tries
to fix an earlier mismatch.
liyuqian added a commit that referenced this pull request Apr 23, 2020
This avoids the possible matrix mismatch between RasterCache::Get and
RasterCacheResult::draw. See
#17790 for an example that tries
to fix an earlier mismatch.
@liyuqian liyuqian deleted the fix_test branch April 23, 2020 23:25
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants