1. 21 Sep, 2017 1 commit
  2. 14 Sep, 2017 1 commit
  3. 31 Aug, 2017 1 commit
    • Devon Carew's avatar
      More frame events (#11747) · 8c36ccf5
      Devon Carew authored
      * Revert "Revert "fire service protocol events for frames (#11565)" (#11727)"
      
      This reverts commit f25e2f52.
      
      * move the postEvent() call into a separate method
      8c36ccf5
  4. 22 Aug, 2017 2 commits
  5. 04 Aug, 2017 1 commit
  6. 27 Jul, 2017 2 commits
  7. 21 Jul, 2017 1 commit
    • Ian Hickson's avatar
      Add documentation and clean up code. (#11330) · 8f56f6fd
      Ian Hickson authored
      Mainly, this adds documentation to members that were previously
      lacking documentation.
      
      It also adds a big block of documentation about improving performance
      of widgets.
      
      This also removes some references to package:collection and adds
      global setEquals and listEquals methods in foundation that we can use.
      (setEquals in particular should be much faster than the
      package:collection equivalent, though both should be faster as they
      avoid allocating new objects.) All remaining references now qualify
      the import so we know what our remaining dependencies are.
      
      Also lots of code reordering in Flutter driver to make the code
      consistent and apply the style guide more thoroughly.
      8f56f6fd
  8. 19 Jul, 2017 1 commit
  9. 21 Jun, 2017 3 commits
  10. 02 Jun, 2017 1 commit
    • Ian Hickson's avatar
      Sprinkle some mixin magic incantations (#10442) · 9eae8b83
      Ian Hickson authored
      This prevents some of our mixins from being subclassed.
      
      Also, move mixins to using 'extends' instead of 'implements' for
      future compatibility with Dart changes.
      
      Also, rename a class that had Mixin in the name but was not a mixin.
      9eae8b83
  11. 12 May, 2017 1 commit
  12. 05 May, 2017 1 commit
  13. 02 May, 2017 1 commit
    • Ian Hickson's avatar
      Flush microtasks after transient callbacks are run. (#9702) · e8c46927
      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.
      e8c46927
  14. 28 Apr, 2017 1 commit
  15. 19 Apr, 2017 1 commit
  16. 15 Apr, 2017 1 commit
    • Ian Hickson's avatar
      Support chaining await calls on controllers (#9389) · 14e728d0
      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.
      14e728d0
  17. 07 Apr, 2017 1 commit
  18. 17 Mar, 2017 2 commits
  19. 15 Mar, 2017 1 commit
  20. 08 Mar, 2017 1 commit
  21. 04 Mar, 2017 1 commit
  22. 02 Feb, 2017 1 commit
  23. 13 Jan, 2017 1 commit
  24. 06 Jan, 2017 1 commit
  25. 29 Nov, 2016 1 commit
  26. 24 Nov, 2016 1 commit
  27. 19 Nov, 2016 1 commit
  28. 17 Nov, 2016 1 commit
  29. 01 Nov, 2016 1 commit
  30. 26 Sep, 2016 1 commit
    • Ian Hickson's avatar
      Turn off AnimationControllers when not in use (#5902) · 9e673853
      Ian Hickson authored
      This requires all AnimationController objects to be given a
      TickerProvider, a class that can create the Ticker.
      
      It also provides some nice mixins for people who want to have their
      State provide a TickerProvider. And a schedulerTickerProvider for those
      cases where you just want to see your battery burn.
      
      Also, we now enforce destruction order for elements.
      9e673853
  31. 08 Sep, 2016 1 commit
    • Ian Hickson's avatar
      Make tests more realistic (#5762) · 5bc8888e
      Ian Hickson authored
      Previously, pumpWidget() would do a partial pump (it didn't trigger
      Ticker callbacks or post-frame callbacks), and pump() would do a full
      pump. This patch brings them closer together. It also makes runApp run a
      full actual frame, rather than skipping the transient callback part of
      the frame logic. Having "half-frames" in the system was confusing and
      could lead to bugs where code expecting to run before the next layout
      pass didn't because a "half-frame" ran first.
      
      Also, make Tickers start ticking in the frame that they were started in,
      if they were started during a frame. This means we no longer spin a
      frame for t=0, we jump straight to the first actual frame.
      
      Other changes in this patch:
      
      * rename WidgetsBinding._runApp to WidgetsBinding.attachRootWidget, so
        that tests can use it to more accurately mock out runApp.
      
      * allow loadStructuredData to return synchronously.
      
      * make handleBeginFrame handle not being given a time stamp.
      
      * make DataPipeImageProvider.loadAsync protected (rather than private),
        and document it. There wasn't really a reason for it to be private.
      
      * fix ImageConfiguration.toString.
      
      * introduce debugPrintBuildScope and debugPrintScheduleBuildForStacks,
        which can help debug problems with widgets getting marked as dirty but
        not cleaned.
      
      * make debugPrintRebuildDirtyWidgets say "Building" the first time and
        "Rebuilding" the second, to make it clearer when a widget is first
        created. This makes debugging widget lifecycle issues much easier.
      
      * make debugDumpApp more resilient.
      
      * debugPrintStack now takes a label that is printed before the stack.
      
      * improve the banner shown for debugPrintBeginFrameBanner.
      
      * various and sundry documentation fixes
      5bc8888e
  32. 07 Sep, 2016 1 commit
  33. 29 Aug, 2016 1 commit
    • Ian Hickson's avatar
      Fix some hero observer bugs (#5633) · dd2251ec
      Ian Hickson authored
      1: If a route is already dismissed when it's popped, there's no point
      trying to animate heroes, because it's going to be gone before the
      heroes code can look at it.
      
      2: If a hero animation finishes just as a new one is starting, we
      previously blew away the state for the starting one. Now we correctly
      segregate the "starting up quest" variables from the "actively ongoing
      quest" variables.
      dd2251ec
  34. 03 Aug, 2016 1 commit
  35. 29 Jul, 2016 1 commit