- 02 May, 2017 1 commit
-
-
Ian Hickson authored
This splits the frame pipeline into two, beginFrame and drawFrame. As part of making this change I added some debugging hooks that helped debug the issues that came up: * I added debugPrintScheduleFrameStacks which prints a stack whenever a frame is actually scheduled, so you can see why frames are being scheduled. * I added some toString output to EditableText and RawKeyboardListener. * I added a scheduler_tester.dart library for scheduler library tests. * I changed the test framework to flush microtasks before pumping. * Some asserts that had the old string literal form were replaced by asserts with messages. I also fixed a few subtle bugs that this uncovered: * setState() now calls `ensureVisualUpdate`, rather than `scheduleFrame`. This means that calling it from an AnimationController callback does not actually schedule an extra redundant frame as it used to. * I corrected some documentation.
-
- 15 Apr, 2017 1 commit
-
-
Ian Hickson authored
With this patch, you can do: ```dart Future<Null> foo() async { try { await controller.forward().orCancel; await controller.reverse().orCancel; await controller.forward().orCancel; } on TickerCanceled { // did not complete } } ``` ...in a State's async method, and so long as you dispose of the controller properly in your dispose, you'll have a nice way of doing animations in sequence without leaking the controller. try/finally works as well, if you need to allocate resources and discard them when canceled. Simultaneously, you can do: ```dart Future<Null> foo() async { await controller.forward().orCancel; await controller.reverse().orCancel; await controller.forward().orCancel; } ``` ...and have the same effect, where the method will just silently hang (and get GC'ed) if the widget is disposed, without leaking anything, if you don't need to catch the controller being killed. And all this, without spurious errors for uncaught exceptions on controllers.
-