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

Allow freezing a texture. #5938

Merged
merged 3 commits into from
Aug 7, 2018
Merged

Allow freezing a texture. #5938

merged 3 commits into from
Aug 7, 2018

Conversation

amirh
Copy link
Contributor

@amirh amirh commented Aug 3, 2018

This is needed to avoid jank when resizing an embedded Android view.
See flutter/flutter#19572 (comment) for more details.

This is needed to avoid jank when resizing an embedded Android view.
See
flutter/flutter#19572 (comment)
@amirh
Copy link
Contributor Author

amirh commented Aug 3, 2018

@chinmaygarde I'm not sure what would be the iOS equivalent of skipping SurfaceTextueUpdateTexImage, any ideas?
(I only need this on Android, but it will be nice to keep it symmetric on iOS as well)

@amirh amirh changed the title [WIP] Allow freezing a texture. Allow freezing a texture. Aug 6, 2018
@amirh
Copy link
Contributor Author

amirh commented Aug 6, 2018

Implemented the freeze for iOS as well, @chinmaygarde want to take a look?

@@ -235,11 +235,13 @@ class SceneBuilder extends NativeFieldWrapperClass2 {
/// Adds a backend texture to the scene.
///
/// The texture is scaled to the given size and rasterized at the given offset.
void addTexture(int textureId, { Offset offset: Offset.zero, double width: 0.0, double height: 0.0 }) {
///
/// If `freeze` is true new frames will not be consumed from the texture.
Copy link
Member

Choose a reason for hiding this comment

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

Can this docstring be more detailed please?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, can you help me by explaining what wasn't clear when you read this?

Copy link
Member

Choose a reason for hiding this comment

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

  • Who not consume the textures?
  • When should the flag be set?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, rewrote the comment PTAL.

@amirh
Copy link
Contributor Author

amirh commented Aug 7, 2018

Woops had a bad merge fixing

@amirh amirh merged commit 7e0bb3b into flutter:master Aug 7, 2018
@amirh amirh deleted the freeze_texture branch August 7, 2018 21:43
liyuqian added a commit to liyuqian/flutter that referenced this pull request Aug 7, 2018
b3e866e Call drawPath without clip if possible (flutter/engine#5952)
7e0bb3b Allow freezing a texture. (flutter/engine#5938)
3cbb5e2 Persist DartCallbackCache contents across launches (flutter/engine#5947)
953570a libtxt: truncate paragraph width to an integer in order to match Blink's behavior (flutter/engine#5962)
amirh added a commit to amirh/flutter that referenced this pull request Aug 8, 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](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 added a commit to flutter/flutter that referenced this pull request Aug 8, 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](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.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants