Rename GPU thread to raster thread in API docs (#53422)

dev/benchmarks/complex_layout/test_memory/scroll_perf.dart

@@ -34,9 +34,9 @@ Future<void> main() async {
   ));
   await SchedulerBinding.instance.endOfFrame;
 
-  /// Wait 50ms to allow the GPU thread to actually put up the frame. (The
-  /// endOfFrame future ends when we send the data to the engine, before the GPU
-  /// thread has had a chance to rasterize, etc.)
+  /// Wait 50ms to allow the raster thread to actually put up the frame. (The
+  /// endOfFrame future ends when we send the data to the engine, before
+  /// the raster thread has had a chance to rasterize, etc.)
   await Future<void>.delayed(const Duration(milliseconds: 50));
   debugPrint('==== MEMORY BENCHMARK ==== READY ====');
 

dev/integration_tests/ui/lib/screenshot.dart

@@ -6,8 +6,8 @@ import 'package:flutter/material.dart';
 import 'package:flutter_driver/driver_extension.dart';
 
 /// This sample application creates a hard to render frame, causing the
-/// driver script to race the GPU thread. If the driver script wins the
-/// race, it will screenshot the previous frame. If the GPU thread wins
+/// driver script to race the raster thread. If the driver script wins the
+/// race, it will screenshot the previous frame. If the raster thread wins
 /// it, it will screenshot the latest frame.
 void main() {
   enableFlutterDriverExtension();
@@ -64,7 +64,7 @@ List<Widget> _buildRows(int count) {
 }
 
 /// Builds cells that are known to take time to render causing a delay on the
-/// GPU thread.
+/// raster thread.
 List<Widget> _buildCells(double epsilon) {
   return List<Widget>.generate(15, (int i) {
     return Expanded(

packages/flutter/lib/src/painting/binding.dart

@@ -44,9 +44,9 @@ mixin PaintingBinding on BindingBase, ServicesBinding {
   /// installation or a data wipe. The warm up does not block the main thread
   /// so there should be no "Application Not Responding" warning.
   ///
-  /// Currently the warm-up happens synchronously on the GPU thread which means
-  /// the rendering of the first frame on the GPU thread will be postponed until
-  /// the warm-up is finished.
+  /// Currently the warm-up happens synchronously on the raster thread which
+  /// means the rendering of the first frame on the raster thread will be
+  /// postponed until the warm-up is finished.
   ///
   /// See also:
   ///

packages/flutter/lib/src/painting/shader_warm_up.dart

@@ -24,9 +24,9 @@ import 'package:flutter/foundation.dart';
 /// done before calling [runApp].
 ///
 /// To determine whether a draw operation is useful for warming up shaders,
-/// check whether it improves the slowest GPU frame. Also, tracing with
-/// `flutter run --profile --trace-skia` may reveal whether there is shader-
-/// compilation-related jank. If there is such jank, some long
+/// check whether it improves the slowest frame rasterization time. Also,
+/// tracing with `flutter run --profile --trace-skia` may reveal whether
+/// there is shader-compilation-related jank. If there is such jank, some long
 /// `GrGLProgramBuilder::finalize` calls would appear in the middle of an
 /// animation. Their parent calls, which look like `XyzOp` (e.g., `FillRecOp`,
 /// `CircularRRectOp`) would suggest Xyz draw operations are causing the
@@ -72,7 +72,7 @@ abstract class ShaderWarmUp {
   /// `flutter screenshot --observatory-uri=<uri> --type=skia`
   /// and analyze it with https://debugger.skia.org.
   /// Alternatively, one may run the app with `flutter run --trace-skia` and
-  /// then examine the GPU thread in the observatory timeline to see which
+  /// then examine the raster thread in the observatory timeline to see which
   /// Skia draw operations are commonly used, and which shader compilations
   /// are causing jank.
   @protected

packages/flutter/lib/src/rendering/performance_overlay.dart

@@ -46,12 +46,13 @@ enum PerformanceOverlayOption {
 ///
 /// The overlay shows two time series. The first shows how much time was
 /// required on this thread to produce each frame. The second shows how much
-/// time was required on the GPU thread to produce each frame. Ideally, both
-/// these values would be less than the total frame budget for the hardware on
-/// which the app is running. For example, if the hardware has a screen that
-/// updates at 60 Hz, each thread should ideally spend less than 16ms producing
-/// each frame. This ideal condition is indicated by a green vertical line for
-/// each thread. Otherwise, the performance overlay shows a red vertical line.
+/// time was required on the raster thread (formerly known as the GPU thread)
+/// to produce each frame. Ideally, both these values would be less than
+/// the total frame budget for the hardware on which the app is running.
+/// For example, if the hardware has a screen that updates at 60 Hz, each
+/// thread should ideally spend less than 16ms producing each frame.
+/// This ideal condition is indicated by a green vertical line for each thread.
+/// Otherwise, the performance overlay shows a red vertical line.
 ///
 /// The simplest way to show the performance overlay is to set
 /// [MaterialApp.showPerformanceOverlay] or [WidgetsApp.showPerformanceOverlay]

packages/flutter/lib/src/widgets/performance_overlay.dart

@@ -8,13 +8,14 @@ import 'framework.dart';
 
 /// Displays performance statistics.
 ///
-/// The overlay show two time series. The first shows how much time was required
-/// on this thread to produce each frame. The second shows how much time was
-/// required on the GPU thread to produce each frame. Ideally, both these values
-/// would be less than the total frame budget for the hardware on which the app
-/// is running. For example, if the hardware has a screen that updates at 60 Hz,
-/// each thread should ideally spend less than 16ms producing each frame. This
-/// ideal condition is indicated by a green vertical line for each thread.
+/// The overlay shows two time series. The first shows how much time was
+/// required on this thread to produce each frame. The second shows how much
+/// time was required on the raster thread (formerly known as the GPU thread)
+/// to produce each frame. Ideally, both these values would be less than
+/// the total frame budget for the hardware on which the app is running.
+/// For example, if the hardware has a screen that updates at 60 Hz, each
+/// thread should ideally spend less than 16ms producing each frame.
+/// This ideal condition is indicated by a green vertical line for each thread.
 /// Otherwise, the performance overlay shows a red vertical line.
 ///
 /// The simplest way to show the performance overlay is to set

packages/flutter_driver/lib/src/driver/driver.dart

@@ -515,15 +515,16 @@ abstract class FlutterDriver {
   ///
   ///  HACK: There will be a 2-second artificial delay before screenshotting,
   ///        the delay here is to deal with a race between the driver script and
-  ///        the GPU thread. The issue is that driver API synchronizes with the
-  ///        framework based on transient callbacks, which are out of sync with
-  ///        the GPU thread. Here's the timeline of events in ASCII art:
+  ///        the raster thread (formerly known as the GPU thread). The issue is
+  ///        that driver API synchronizes with the framework based on transient
+  ///        callbacks, which are out of sync with the raster thread.
+  ///        Here's the timeline of events in ASCII art:
   ///
   ///        -------------------------------------------------------------------
   ///        Without this delay:
   ///        -------------------------------------------------------------------
   ///        UI    : <-- build -->
-  ///        GPU   :               <-- rasterize -->
+  ///        Raster:               <-- rasterize -->
   ///        Gap   :              | random |
   ///        Driver:                        <-- screenshot -->
   ///
@@ -532,7 +533,7 @@ abstract class FlutterDriver {
   ///        `screenshot()`. The gap is random because it is determined by the
   ///        unpredictable network communication between the driver process and
   ///        the application. If this gap is too short, which it typically will
-  ///        be, the screenshot is taken before the GPU thread is done
+  ///        be, the screenshot is taken before the raster thread is done
   ///        rasterizing the frame, so the screenshot of the previous frame is
   ///        taken, which is wrong.
   ///
@@ -540,11 +541,11 @@ abstract class FlutterDriver {
   ///        With this delay, if we're lucky:
   ///        -------------------------------------------------------------------
   ///        UI    : <-- build -->
-  ///        GPU   :               <-- rasterize -->
+  ///        Raster:               <-- rasterize -->
   ///        Gap   :              |    2 seconds or more   |
   ///        Driver:                                        <-- screenshot -->
   ///
-  ///        The two-second gap should be long enough for the GPU thread to
+  ///        The two-second gap should be long enough for the raster thread to
   ///        finish rasterizing the frame, but not longer than necessary to keep
   ///        driver tests as fast a possible.
   ///
@@ -552,7 +553,7 @@ abstract class FlutterDriver {
   ///        With this delay, if we're not lucky:
   ///        -------------------------------------------------------------------
   ///        UI    : <-- build -->
-  ///        GPU   :               <-- rasterize randomly slow today -->
+  ///        Raster:               <-- rasterize randomly slow today -->
   ///        Gap   :              |    2 seconds or more   |
   ///        Driver:                                        <-- screenshot -->
   ///

packages/flutter_driver/lib/src/driver/timeline_summary.dart

@@ -74,8 +74,8 @@ class TimelineSummary {
     return _percentileInMillis(_extractGpuRasterizerDrawDurations(), p);
   }
 
-  /// The number of frames that missed the [kBuildBudget] on the GPU and
-  /// therefore are in the danger of missing frames.
+  /// The number of frames that missed the [kBuildBudget] on the raster thread
+  /// and therefore are in the danger of missing frames.
   int computeMissedFrameRasterizerBudgetCount([ Duration frameBuildBudget = kBuildBudget ]) => _extractGpuRasterizerDrawDurations()
       .where((Duration duration) => duration > kBuildBudget)
       .length;

packages/flutter_tools/lib/src/commands/run.dart

@@ -100,7 +100,8 @@ class RunCommand extends RunCommandBase {
       ..addFlag('trace-skia',
         negatable: false,
         help: 'Enable tracing of Skia code. This is useful when debugging '
-              'the GPU thread. By default, Flutter will not log skia code.',
+              'the raster thread (formerly known as the GPU thread). '
+              'By default, Flutter will not log skia code.',
       )
       ..addOption('trace-whitelist',
         help: 'Filters out all trace events except those that are specified in '