In Flutter, the “cursor” you see when typing into a TextField (or any other text input widget) is actually drawn (painted) by a lower-level rendering object called RenderEditable, which lives inside an EditableText widget. Here is a conceptual overview of how it works:
TextField:
The high-level widget most developers use. It wraps lower-level widgets to handle text input, focus, styling, etc.
EditableText:
Below is an example GitHub Actions workflow updated for the new monorepo structure, where the former Engine repository now resides inside an engine/ folder in the main Flutter repository. This assumes you still want to build the native engine artifacts (e.g., for Linux, Windows, macOS, iOS, Android, Web) using GN + Ninja (i.e., the Chromium-based build system).
Important: The monorepo is still in flux as of this writing. The steps below might require adjustments based on the latest official instructions from the Flutter repository. The general ideas—installing
depot_tools, runninggclient sync, runninggn gen, and thenninja—remain the same, but you may need to tweak paths and GN args.
engine/ folder).
| Below is an example GitHub Actions workflow that demonstrates **one possible approach** to building multiple variants (debug, profile, release) of the Flutter Engine on Linux, Windows, and macOS. | |
| > **Important Caveats** | |
| > 1. Building the Flutter Engine is fairly complex and typically uses [Chromium’s build tools](https://commondatastorage.googleapis.com/chrome-infra-docs/flat/developers_guide/index.html) (gclient, GN, ninja, etc.). | |
| > 2. The official Flutter Engine uses [LUCI](https://chromium.googlesource.com/infra/luci/luci-py) for continuous integration, not GitHub Actions. | |
| > 3. This example is **not** guaranteed to work out of the box for all scenarios, because setting up the full environment for iOS, Android, etc. often involves extra steps (e.g., Xcode installation for iOS, or the Android NDK for Android). | |
| > 4. For a canonical reference on how to build the Flutter Engine locally, consult the [Flutter Engine’s CONTRIBUTING.md](https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#compiling |
Below is an example of how you could change the Flutter framework source to make GestureDetector require an explicit HitTestBehavior (or to change its default). Please note this is a breaking change and would require a carefully managed rollout to avoid breaking existing apps.
In the Flutter repo, the relevant code lives in:
flutter/packages/flutter/lib/src/widgets/gesture_detector.dart
Below is an explanation of why this happens, followed by several approaches to fix or work around the issue.
By default, GestureDetector uses HitTestBehavior.deferToChild. This means that the GestureDetector will only receive pointer events if its child reports that it hit the pointer event. A Padding widget by itself does not consider its padded space as “hit-testable” area—so taps on the space around the text are ignored by the child.
If you want the entire region (including the padding) to be tappable, you need to change the behavior to either HitTestBehavior.opaque or HitTestBehavior.translucent.
Why this approach is problematic
Over-Complex Architecture:
The proposed solution sets up a multi-stage pipeline:
.dart_tool.This layering of multiple components (desktop environment, web viewer, frame streaming, custom asset bundle, etc.) makes the system unusually complex. Complexity increases the risk of bugs, maintenance overhead, and reduces the predictability of future compatibility. Each added layer—especially streaming pixels and events across processes—introduces new potential points of failure and performance bottlenecks.
Below is an updated fix that aligns with the current version of the vector_graphics source code you provided. The original issue involved a runtime crash (_TypeError) occurring when attempting to draw <image> elements. With the newer code that uses ImmutableBuffer and ImageDescriptor, the decoding pipeline is already correct. The likely cause of the crash is that onDrawImage may be invoked before the image has finished decoding or if the image failed to decode, resulting in a null lookup from the _images map.
To address this safely, we should:
_images before drawing.Updated onDrawImage method:
Issue Explanation
The reported error involves a runtime crash when the vector_graphics package attempts to draw an <image> element from an SVG. The stack trace suggests a TypeError is happening during onDrawImage, likely due to the decoding of image bytes into a Dart/Flutter UI image object not producing the expected type.
Prior to Flutter 3.10, decodeImageFromList was the conventional method to decode images from byte arrays. However, with updated Flutter versions and web compatibility changes, decodeImageFromList on the web may not return the expected ui.Image type, causing type errors at runtime. Instead, it's recommended to use the newer image decoding approach that involves ImmutableBuffer, ImageDescriptor, and Codec.
Root Cause
onDrawImage method in FlutterVectorGraphicsListener is expecting a ui.Image, but the decoding method used might be returning something else or failing silently, leading to a TypeError.
Note: Graphite is a relatively new and experimental GPU rendering backend within Skia, and as of now, Flutter does not officially support it out-of-the-box. Integrating Graphite into Flutter involves building a custom Flutter engine with the appropriate Skia flags enabled. The process below assumes familiarity with building the Flutter engine from source and working with GN/Ninja build systems.
Prerequisites:
| import 'package:flutter/material.dart'; | |
| import 'package:audioplayers/audioplayers.dart'; | |
| class TextSlide { | |
| /// Hex color for the text. Defaults to white (#ffffff) if missing or empty. | |
| final String textColor; | |
| /// Title of the slide. Defaults to empty string if missing. | |
| final String title; |