1. 29 Apr, 2019 2 commits
  2. 25 Apr, 2019 1 commit
  3. 19 Apr, 2019 3 commits
  4. 15 Apr, 2019 2 commits
  5. 11 Apr, 2019 2 commits
  6. 10 Apr, 2019 1 commit
  7. 09 Apr, 2019 1 commit
  8. 05 Apr, 2019 1 commit
  9. 30 Mar, 2019 1 commit
  10. 29 Mar, 2019 1 commit
  11. 28 Mar, 2019 1 commit
  12. 26 Mar, 2019 1 commit
  13. 22 Mar, 2019 1 commit
  14. 21 Mar, 2019 1 commit
  15. 10 Mar, 2019 1 commit
  16. 08 Mar, 2019 1 commit
  17. 06 Mar, 2019 1 commit
    • Dan Field's avatar
      Test reporter (#28297) · 20e0f13c
      Dan Field authored
      * Wrap test.main with a custom processor
      * Report test results to bigquery table
      20e0f13c
  18. 01 Mar, 2019 2 commits
  19. 27 Feb, 2019 1 commit
  20. 26 Feb, 2019 1 commit
  21. 25 Feb, 2019 1 commit
  22. 23 Feb, 2019 2 commits
  23. 22 Feb, 2019 2 commits
    • liyuqian's avatar
      Shader warm up (#27660) · a44f174e
      liyuqian authored
      This patch adds a default shader warm up process which moves shader compilation from the animation time to the startup time. This also provides an extension for `runApp` so developers can customize the warm up process.
      
      This should reduce our worst_frame_rasterizer_time_millis from ~100ms to ~20-30ms for both flutter_gallery and complex_layout benchmarks. Besides, this should also have a significant improvement on 90th and 99th percentile time (50%-100% speedup in some cases, but I haven't tested them thoroughly; I'll let our device lab collect the data afterwards).
      
      The tradeoff the is the startup time (time to first frame). Our `flutter run --profile --trace-startup` seems to be a little noisy and I see about 100ms-200ms increase in that measurement for complex_layout and flutter_gallery. Note that this only happens on the first run after install or data wipe. Later the Skia persistent cache will remove the overhead.
      
      This also adds a cubic_bezier benchmark to test the custom shader warm up process.
      
      This should fix https://github.com/flutter/flutter/issues/813 (either by `defaultShaderWarmUp`, or a `customShaderWarmUp`).
      a44f174e
    • Stanislav Baranov's avatar
  24. 21 Feb, 2019 2 commits
  25. 15 Feb, 2019 1 commit
  26. 13 Feb, 2019 1 commit
  27. 07 Feb, 2019 1 commit
    • Greg Spencer's avatar
      Add a keyboard key code generator. (#27620) · 2aad5931
      Greg Spencer authored
      This adds a keycode generator that incorporates input from the Chromium and Android source trees, as well as some local tables, to generate static constants for the LogicalKeyboardKey and PhysicalKeyboardKey classes, as well as mappings from each of the platforms we support so far (currently only Android and Fuchsia).
      
      This code generator parses the input files, generates an intermediate data structure (`key_data.json`) that is checked in, and then generates the Dart sources for these classes and some static maps that will also be checked in (but are not included in this PR).
      
      The idea is that these codes don't change often, and so we don't need to generate them on every build, but we would like to be able to update them easily in the future if new data becomes available. If the existing data disappears or becomes unusable, we can maintain the checked-in data structure by hand if necessary, and still be able to generate the code.
      
      This PR only contains the code generator, not the classes themselves. In another follow-on PR, I'll run the generator and check in the output of the generator.
      2aad5931
  28. 06 Feb, 2019 2 commits
  29. 05 Feb, 2019 1 commit
  30. 04 Feb, 2019 1 commit