Skip to content

Conversation

@amirh
Copy link
Contributor

@amirh amirh commented Aug 6, 2018

Resizing an AndroidView happens asynchronously (as it requires thread
hopping from the ui thread to the platform thread).
While waiting for the resize to complete the framework does exactly when
the embedded view has been resized. This leads to pretty bad jank as the
framework might paint the embedded view with a wrong size.

We're working around this by freezing the texture frame while resizing
until we are sure that the next frame has the new size. This is how it
looks with the workaround:

This is how it looks before and after the workaround:

Before (janky) After (less janky)
resize_before resize_after

Fixes #19572

Copy link
Member

@jason-simmons jason-simmons left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

Choose a reason for hiding this comment

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

typo: "size is ready"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Copy link
Member

Choose a reason for hiding this comment

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

style: align this with the line above

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Resizing an AndroidView happens asynchronously (as it requires thread
hopping from the ui thread to the platform thread).
While waiting for the resize to complete the framework does exactly when
the embedded view has been resized. This leads to pretty bad jank as the
framework might paint the embedded view with a wrong size.

We're working around this by freezing the texture frame while resizing
until we are sure that the next frame has the new size. This is how it
looks with the workaround:

This is how it looks before and after the workaround:

Before (janky) |  After (less janky)
:--------|---------:
![resize_before](https://user-images.githubusercontent.com/1024117/43669639-51bfd0ae-9739-11e8-8cbe-96e36f2460d2.gif) | ![resize_after](https://user-images.githubusercontent.com/1024117/43669647-62e885a6-9739-11e8-8aa4-beb74e979995.gif)

This depends on flutter/engine#5938. Additionaly right now the engine completes
the resize call immediately, a following PR will change it to complete
after a frame with the new size is ready.
@amirh amirh merged commit b7a6c16 into flutter:master Aug 8, 2018
@amirh amirh deleted the resize_jank branch August 8, 2018 20:55
/// The identity of the backend texture.
final int textureId;

final bool freeze;
Copy link
Contributor

Choose a reason for hiding this comment

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

can you add some dartdocs to this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sent #20383

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 10, 2021
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.

Reduce visual artifacts when resizing embedded Android views

4 participants