Regression in AnimatedContainer behavior on CanvasKit and DomCanvas Web builds on master and dev channel release builds

[rydmike]

Steps to Reproduce

The issue described below has been observed on master channel starting from at least
least 1.21.0-8.0.pre.168 to at least master 1.21.0-10.0.pre.90.

---

UPDATE 7.9.2020
It has later been observed that the here described issues also applies to DomCanvas release builds, but not to debug builds.
The issue has regressed all the way down to Channel dev, 1.22.0-9.0.pre but has not yet been observed on Channel beta 1.21.0-9.2.pre.

---

Observed issues:

1. Animations that scale and push other content on the canvas animate with severe jank and delay, almost like there is no animation at all.
2. Theme change animations are really janky and sometimes do not even end up completing on the right end result (frame).
3. Window re-sizing is very unresponsive and re-scales content only after a significant delay. Window re-scaling has always been quite janky on all channels and any platform, but this is off the chart.

All web versions demonstrated here were built using:

flutter run -d chrome --release --dart-define=FLUTTER_WEB_USE_SKIA=true --dart-define=FLUTTER_WEB_USE_EXPERIMENTAL_CANVAS_TEXT=true

Expected results

As temporary finding of expected results, these Tweet videos are representative of what it should look like:

I just remade the Web build shown here with Channel beta, 1.20.0:
It still looks and runs as expected (OK) and the same as in the demo here:
Using green theme https://twitter.com/RydMike/status/1293392861816410112?s=20

I also remade the Windows build shown here with Channel master, 1.21.0-10.0.pre.9
Using orange theme https://twitter.com/RydMike/status/1293392864790155264?s=20
It also still look and runs as expected and as in the tweeted video, so all OK here too.

This version is built with latest stable and running on an Android emulator.
Using blue theme https://twitter.com/RydMike/status/1293393473312301057?s=20
It is fine too and shows expected behavior. (OK)

Actual failed results

When building the same app for Web with Channel master, 1.21.0-10.0.pre.9
We still get the same janky (FAIL) version as the one shown in this Tweet video
Using red theme https://twitter.com/RydMike/status/1293392860260204544?s=20
that was made with a bit older master revision 1.21.0-8.0.pre.175 but the newer build with Channel master, 1.21.0-10.0.pre.9 looks and behaves the same.

The differences from the above shown expected behavior is very obvious and significant.

• It is like there is no animation at all for when the menus animate in/out and move other content around.
• Same result can be observed when resizing the browser window. It shows more extreme resize delay and jank than ever before. Resizing windows has never been good on any device or platform, but this version is on a new level.
• Theme change animation are also extremely janky and some the last few frames in the themes are not repainted, so the new theme is not fully reached. Shown on the right sidebar in the demo. I have more examples of this to be added later if needed.

NOTE: The links to the tweet videos unfortunately did not open the desired post in enlarged/focused mode when I tried, even if the links were copied in that mode and from the exact post in question. But based on the comments and the different colored themes used in the demo on each video, it should be clear which one is which.

More info to be added

This is just a pre-report of the issue. I will be complementing and updating it with more info if so required. Unfortunately the videos and GIF recordings I have now are to large to post directly directly in the issue and the app used to demo it in the above Tweet videos is a bit too long and involved to be a good issue sample. (Although I do plan to release the code for the tech demo app shown in the video and a few packages that it is using later, so in principle I could use it too, as soon as it is bit more complete)

To be added

1. Shorter Gif screen recordings showing the exact differences clearly.
2. Produce a short code sample that shows the issues and is available as a repo with live demo versions built with beta and master.

Flutter Doctor

flutter doctor -v
[√] Flutter (Channel master, 1.21.0-10.0.pre.90, on Microsoft Windows [Version 10.0.18363.900], locale en-US)
    • Flutter version 1.21.0-10.0.pre.90 at c:\src\flutter
    • Framework revision 88118bcbd1 (2 hours ago), 2020-08-14 00:17:43 +0200
    • Engine revision 7571e7c380
    • Dart version 2.10.0 (build 2.10.0-11.0.dev)


[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at C:\Users\mryds\AppData\Local\Android\sdk
    • Platform android-28, build-tools 28.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.6.5)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.6.30320.27
    • Windows 10 SDK version 10.0.18362.0

[√] Android Studio (version 4.0)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[√] IntelliJ IDEA Community Edition (version 2019.2)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.3.1
    • Flutter plugin version 35.3.3
    • Dart plugin version 192.7402

[√] VS Code (version 1.48.0)
    • VS Code at C:\Users\mryds\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.13.2

[√] Connected device (5 available)
    • Nexus 7 (mobile)  • 0a99f5e8   • android-arm    • Android 6.0.1 (API 23)
    • Windows (desktop) • windows    • windows-x64    • Microsoft Windows [Version 10.0.18363.900]
    • Web Server (web)  • web-server • web-javascript • Flutter Tools
    • Chrome (web)      • chrome     • web-javascript • Google Chrome 84.0.4147.105
    • Edge (web)        • edge       • web-javascript • Microsoft Edge 84.0.522.52

• No issues found!

[rydmike]

@mariamhas and @yjbanov, as discussed I now started stub for this issue, since it has been on master for a few days already.

Since it is master I'm fully aware that unexpected issues like this might occur, which is also why I was waiting for it mature a bit first to see if it sticks around, before I report it.

I will add more info later if needed. Something has clearly changed on master and somebody probably knows what. It is clearly not an improvement. I was thinking maybe there was some work going on to make window resizing better and did not pan out, but then why would that affect the animations when content is being resized/moved in same container canvas size and why would Windows and Android builds on master not be affected.

Just for info the resizing of the rail/menu and sidebar in the demo is just using a simple standard AnimatedContainer where the width changes and the rest of the layout responds to being in another width as the "body" area shrinks/grows.

[rydmike]

1. Additional and more detailed GIF screen recording comparisons

Here are additional screen recordings comparing each observed issue when building on:

A) Channel master, 1.21.0-10.0.pre.94 - Windows build (GOLDEN theme)
B) Channel beta, 1.20.0 - Web SKIA build (GREEN theme)
C) Channel master, 1.21.0-10.0.pre.94 - Web SKIA build (RED theme)

General observation is that A -> B -> C is the path of loss of fluidity in animations. With B for some cases being very close to A and C is just broken.

ISSUE 1) Expanding menu animation pushing other content

A. Windows version built with Master = OK

As expected this one is smooth and nice.

B. Web SKIA built with Beta = OK

This one looks pretty smooth too.

C. Web SKIA built with Master = FAIL

This one is very broken with menus just flashing in and out, no animation to talk about.

[rydmike]

ISSUE 2) Theme change animations

A. Windows version built with Master = OK

As expected this one is smooth and nice.

B. Web SKIA built with Beta = OK

This one looks OK too, pretty much the same as on Windows with regards to smoothness.

C. Web SKIA built with Master = FAIL

This one is very broken, very janky animation and the theme even fails to animate to the correct end result in some cases. I had to open and close the menu for it to rebuild to get the correct theme.

[rydmike]

ISSUE 3) Resizing the Canvas

A. Windows version built with Master = OK

As expected this one is fine, well it is as it has always been, it is far from where it needs to be, it is janky, but unchanged from previous behavior, so as expected.

B. Web SKIA built with Beta = OK

In this case the WEB SKIA build with Beta is not really as close to the Windows build as it where with issues 1 and 2 where there was hard to notice any difference. The main difference is that menus when they change and animate due to canvas size change, they do so much less smoothly, they clearly jump quite a bit more. The jankiness in the resize of the grid items due to the resizing of the canvas is also a bit more pronounced than it is in A. Still these are roughly as they have always been on WEB Skia builds, so results are as expected.

C. Web SKIA built with Master = FAIL (but probably not the canvas resize that is the issue)

Based on looking at this a bit closer, I am ready to conclude that it is not actually the re-sizing of the canvas that has any issue. The Grid items seem to move and re-scale about as smoothly as they do in B and the jarring issue in the resizing comes from the extreme jank when the menu jumps out and even does it as some kind of a grey box first. This would thus be the same case as issue 1).

[rydmike]

Summary of findings based on visual observations of the differences

When you build for Web target with CanvasKit and CanvasText on Channel master from at least rev 1.21.0-8.0.pre.168 up to at least 1.21.0-10.0.pre.94, something odd is going on when using e.g. AnimatedContainer to change its size, it gets very janky and behaves odd. I suspect the observed issue with the animated theme change has the same root cause, but that is just a gut feeling.

I do not know exactly when it has broken, as I only occasionally check web builds, mostly I build with Windows as target, as it runs so much smoother and builds much faster.

[TahaTesser]

Hi @rydmike
Would love that short code sample to reproduce the issue thoroughly
Thank you

[rydmike]

@TahaTesser Of course, it is still on the "To be added" todo list above. I will try to add one over the weekend.

[rydmike]

Issue update with sample code

While building a more isolated demo case I found the cause of the issue and isolated it.

That it caused an issue is perhaps as such, not so surprising, it is even quite obvious that it might be a problematic use case. What is perhaps much more interesting is, that what was causing the major jank on Web with Master channel Canvas Kit builds, did not have any serious impact on channel master for Windows builds or even for Web CanvasKit builds on channel beta, or stable for Android builds. Due to this I suspect that some optimizations that might have been done to Web on master channel, might be behind this regression, but that is pure speculation.

The example issue demo turned out quite elaborate, apologies for that. At least it is fun to play with. 😊
It is also a bit messy since I wanted an example in one file that can also be run in DartPad just to easily check how it works on the DomCavas build it uses.

Another reason why the issue demo case got so elaborate is because at first I could not reproduce it with the simpler case I started with. So I ended up adding more and more pieces of the original case where the issue was present, until I eventually found the line that caused the issue. The cause was a line that should not have been in the original either, it was not even needed anymore, a remnant from an earlier revision, well at least I got that cleared out as well.

The culprit

Turns out using an AnimatedContainer where you change the width to animate it, is fine, but in hindsight and for quite obvious reasons, it is not a good idea to also assign it a color that depends on a Theme.of(context) color. It is however quite interesting that doing so caused both the animation jank presented in above earlier GIFs, as well as the theme change animation breaking. Had they happened (or been observable) on Windows and/or Android builds, the quite obvious cause would probably have been easier to suspect.

Demo source

The source code for the issue demo is here:
https://gist.github.com/rydmike/2e8e6a4cc9126dbe6f95e81e674f6d6b

Web CanvasKit Channel Beta - OK

Here is a LIVE version that was built with Channel beta, 1.20.2, release mode with CanvasKit and CanvasText:

https://rydmike.github.io/animatedcontainerbeta/#/

This version runs fine and is surprisingly smooth even with the issue “switch” turned, if you turn off the issue switch, the panel size changes are a tad smoother, but hard to see at a quick glance. The theme change looses that extra delayed theme change cycle the animated side panel goes through. If you build this for Windows desktop on channel master, it behaves pretty much the same as the Web channel beta build, sure even smoother of course, to the point that it is hard to notice any difference with the issue switch on or off.

Gif demo showing that it runs "OK" also with the issue switch ON:

Web CanvasKit Channel Master – Some regression is causing different behavior

The live Web version of the same issue demo built with Channel master 1.21.0-10.0.pre.111 can be found here:

https://rydmike.github.io/animatedcontainermaster/#/

It has the same animation jank and the breaking theme switch animation as the earlier above shown GIF recordings. If you toggle the switch that avoids the cause of the issue, it runs fine.

Often when you toggle the theme switch and it stops in an unfinished theme change state and then turn OFF the issue switch, it no longer works at all when trying toggle the panel size after turning the issue switch off. At that point I assume something broke in the AnimatedContainer state. A reload (browser refresh) of the SPA demo solves that hung situation. Switching the issue switch from ON to OFF, seems to work fine if you do not do it in a state where the theme mode animation did not complete properly. I guess this is some weird side effect of the underlying cause.

DartPad version

Not so relevant, but since the code is in a GIST, this issue demo can also easily be run on the latest DartPad version here:
https://dartpad.dartlang.org/2e8e6a4cc9126dbe6f95e81e674f6d6b
It is quite slow when it comes to the animation, but it does not have the issue.

Issue code line

In the demo code the problem causing line can be found at line 178:

color: problemOn ? Theme.of(context).canvasColor : null,

Summary of findings

For the case that led to the discovery of this issue, there is no need for using the color property on the AnimatedContainer with a theme based color. It gets its color from the theme anyway. The property should actually not even have been used where this issue was found, so it can now easily be avoided.

This issue does however reveal that there is some behavior regression currently on master compared to beta channel for this case, when building for CanvasKit. It causes quite a big change in behavior. The issue cannot be observed visually on same master version when building for Windows or device targets. This observed regression may also have other impacts not revealed in this discovery.

[iapicca]

wow, yours is some professional repro code!
is flutter complaining in terminal Cannot find native JavaScript type () for type
it prevented me from (properly) resizing the app?

[rydmike]

@iapicca Thanks, it got a bit more elaborate than it needed to be while I was looking for the cause to be able to replicate it. I could have (probably should have) pulled out all the fluff after I found it, but it looked kind of nice and was fun to play with, so I let it be... 😀 (maybe somebody will find it useful for something else)

The test with DartPad using DomCanvas was just more of an exotic check to see if it works at all. I was surprised that it did, the animation speeds are very sluggish compared to the release mode CanvasKit Beta channel build.

Yes when built with master channel:
https://rydmike.github.io/animatedcontainermaster/#/
It does indeed throw a bunch of JS exceptions in the Chrome console when you toggle panel size, hide show the panel or switch theme mode. If you turn of the line causing the issue, it does not throw does exceptions anymore. I also noticed that sometimes after the exceptions have been thrown, it might lead to that the hide/show or expand/collapse panel switches stop working.

When building for desktop or device on master channel, there are no exceptions in the Flutter console while running it in debug mode, regardless of if the switch that includes/excludes the line that causes an exception in the Web master build is on or off.

The version built with Beta channel does not care if the issue causing line is on or off:
https://rydmike.github.io/animatedcontainerbeta/#/
It does not throw exceptions, not even in the Web CanvasKit build.

This is why I think it is some kind of regression on master channel for Web builds. What its cause might be I have no idea. Maybe a bug, maybe there has been an attempt to optimize out stupid use cases that you should not do, which in this case the theme.of(color) on the animated container certainly is, but even so, it should not break and start throwing exceptions, imo.

For both built versions I also see this error:
flutter_service_worker.js:1 Uncaught (in promise) TypeError: Request failed
When the app is loaded or refreshed (as it is an SPA, so loaded again). This error seems unrelated to this issue, but yes, certainly an issue as as well.