1. 13 Oct, 2023 1 commit
    • Todd Volkert's avatar
      Make constraints a covariant argument in RenderBox.computeDryLayout() (#136432) · bc688cf0
      Todd Volkert authored
      Some render box subclasses have a specific layout contract that is tightly coupled with other render box subclasses (e.g. two private classes in a local project file). In these cases, it is also possible that they use a constraints object that is a subclass of `BoxConstraints`. To allow for this, this change makes the `constraints` argument to `RenderBox.computeDryLayout()` a covariant argument.
      
      For completeness' sake, this updates the other render objects in the rendering package to also use the covariant keyword for this argument.
      bc688cf0
  2. 20 Sep, 2023 1 commit
    • Greg Spencer's avatar
      Remove 'must not be null' comments from painting and rendering libraries. (#134993) · fe9a2c54
      Greg Spencer authored
      ## Description
      
      This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values.
      
      This PR removes them from the painting and rendering libraries.
      
      This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.
      
      In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.
      
      This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases.  I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).
      
      ## Related PRs
      - https://github.com/flutter/flutter/pull/134984
      - https://github.com/flutter/flutter/pull/134991
      - https://github.com/flutter/flutter/pull/134992
      - https://github.com/flutter/flutter/pull/134994
      
      ## Tests
       - Documentation only change.
      fe9a2c54
  3. 10 Aug, 2023 1 commit
  4. 21 Jun, 2023 1 commit
    • Yegor's avatar
      [framework,web] add FlutterTimeline and semantics benchmarks that use it (#128366) · 07772a3d
      Yegor authored
      ## FlutterTimeline
      
      Add a new class `FlutterTimeline` that's a drop-in replacement for `Timeline` from `dart:developer`. In addition to forwarding invocations of `startSync`, `finishSync`, `timeSync`, and `instantSync` to `dart:developer`, provides the following extra methods that make is easy to collect timings for code blocks on a frame-by-frame basis:
      
      * `debugCollect()` - aggregates timings since the last reset, or since the app launched.
      * `debugReset()` - forgets all data collected since the previous reset, or since the app launched. This allows clearing data from previous frames so timings can be attributed to the current frame.
      * `now` - this was enhanced so that it works on the web by calling `window.performance.now` (in `Timeline` this is a noop in Dart web compilers).
      * `collectionEnabled` - a field that controls whether `FlutterTimeline` stores timings in memory. By default this is disabled to avoid unexpected overhead (although the class is designed for minimal and predictable overhead). Specific benchmarks can enable collection to report to Skia Perf.
      
      ## Semantics benchmarks
      
      Add `BenchMaterial3Semantics` that benchmarks the cost of semantics when constructing a screen full of Material 3 widgets from nothing. It is expected that semantics will have non-trivial cost in this case, but we should strive to keep it much lower than the rendering cost. This is the case already. This benchmark shows that the cost of semantics is <10%.
      
      Add `BenchMaterial3ScrollSemantics` that benchmarks the cost of scrolling a previously constructed screen full of Material 3 widgets. The expectation should be that semantics will have trivial cost, since we're just shifting some widgets around. As of today, the numbers are not great, with semantics taking >50% of frame time, which is what prompted this PR in the first place. As we optimize this, we want to see this number improve.
      07772a3d
  5. 16 Jun, 2023 1 commit
  6. 07 Jun, 2023 1 commit
    • fzyzcjy's avatar
      Show error message in release mode when box is not laid out without losing performance (#126302) · 31e3ae89
      fzyzcjy authored
      Close https://github.com/flutter/flutter/issues/126303
      
      When I encounter bugs in production environment saying null pointer error on `return _size!`, I wish I could know more information! However, currently the information is revealed by `assert(hasSize, 'RenderBox was not laid out: $this');`, thus *only* in debug mode can I know what is `this` (and/or more information that can be added), while in release mode I can only see a stack trace saying it is `RenderBox.size` that throws - nothing more :/
      
      Therefore, it is intuitive to add this extra information in release mode. However, will it affect performance? We all know this is in critical path and should be quite careful. Thus I did some experiments: https://godbolt.org/z/zPPPf5969 From my naive understanding of assembly, the two versions of code (`size!` vs `size ?? throw`) has the same assembly, except that they throw different types of errors. In other words, when there is no error, both code should be equivalent; when there is an error, surely the new code will be slower since it calls `this.toString()`, but the error handling process is rare and already heavy, so this is not a problem.
      
      ![image](https://user-images.githubusercontent.com/5236035/236962182-b9450d59-a2ac-426f-8300-3c7edcadf35e.png)
      31e3ae89
  7. 02 Jun, 2023 1 commit
  8. 26 May, 2023 1 commit
    • LongCatIsLooong's avatar
      Move shared inline widget logic to `RenderInlineWidgetContainerDefaults` (#127308) · b5df180a
      LongCatIsLooong authored
      - Added `InlineWidgetContainerDefaults` for deduping inline widget code
      - Added a helper function `WidgetSpan.extractFromInlineSpan` for extracting `WidgetSpan`s and automatically applying text scaling (at widget level)
      - Removed `TextPainter.inlinePlaceholderScales`. I'm going to deprecate the `scale` argument in `TextPainter.addPlaceholder` next, as scaling is now done at the widget level.
      - Added runtime check and comments to make sure nobody is extending `PlaceholderSpan` directly (unfortunately we can't remove `PlaceholderSpan`  without moving RenderEditable and RenderParagraph to the widgets library).
      b5df180a
  9. 16 May, 2023 1 commit
  10. 12 Apr, 2023 1 commit
  11. 23 Mar, 2023 1 commit
  12. 28 Feb, 2023 1 commit
  13. 24 Jan, 2023 1 commit
  14. 21 Jan, 2023 1 commit
  15. 11 Dec, 2022 1 commit
  16. 30 Aug, 2022 1 commit
  17. 10 Aug, 2022 1 commit
  18. 17 Jun, 2022 1 commit
  19. 25 May, 2022 1 commit
  20. 20 May, 2022 1 commit
  21. 19 May, 2022 1 commit
  22. 18 May, 2022 1 commit
  23. 06 May, 2022 2 commits
  24. 14 Apr, 2022 1 commit
  25. 13 Apr, 2022 1 commit
  26. 11 Apr, 2022 1 commit
  27. 21 Mar, 2022 1 commit
  28. 01 Mar, 2022 1 commit
  29. 26 Jan, 2022 1 commit
  30. 21 Jan, 2022 1 commit
  31. 10 Dec, 2021 1 commit
  32. 08 Oct, 2021 4 commits
  33. 27 Sep, 2021 1 commit
  34. 03 Aug, 2021 1 commit
  35. 12 Jun, 2021 1 commit
  36. 26 May, 2021 1 commit