Migrates to using os_log for app logging on iOS 13 and above, macOS
10.11 and above. On older platform, fall back to syslog(), which is what
we used previously.
This re-lands commit 78a8909725bbaeec80870f498d01ea6e56932a3a with a fix.
That commit was reverted in a61dbf2f66b97e85f4d8bf0cfb29a8b3c2640c09.
Migrates to using os_log for app logging on iOS 13 and above, macOS
10.11 and above. On older platform, fall back to syslog(), which is what
we used previously.
This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.
Prior to this change SceneHostBindinds was a ThreadLocal but the
intention was for it to be IsolateLocal. Given that dart
could collect this map on a non-UI thread this caused
use-after-free issues.
This change fixes it by making it keyed on isolate and koid
this is not the ideal solution, this would exist on
dart isolate group data struct. Given that Fuchsia is moving
to use the embedder API, the decision to use this temporary
work around was made.
fixes https://github.com/flutter/flutter/issues/49738
Tonic used to be used by multiple consumers outside of Flutter Engine. Due to
this, it has an unnecessary abstraction layer as well as utilities duplicated in
FML and other engine subsystems. The sole user of Tonic is now the Flutter
Engine. It is intended that the Flutter Engine team now owns this subsystem,
remove unnecessary utilities and document the headers. This is the first step in
the transition. No history is being imported as the initial history was already
lost in the transition of this component to fuchsia.googlesource. As this
component was unmaintained there, I could see no additional value in importing
the history of the patches there.
No functional change. Just moved the repo from //third_party to
//flutter/third_party and updates GN refs.
When down-scaling images, decode encoded images into smaller images
closer to the target size before finally down-scaling them to their
target size. For very large images this can avoid inflating the image
into its full size first before throwing it away. This can help to
significantly reduce peak memory utilization.
On a tangent, we could be even more efficient, if we'd interpret the
cache(Width|Height) as sizing hints.
I also opportunistically added warnings, I don't think a "caching" API
should support scaling images up or changing their aspect ratio.
Broke a fake implementation of Accessibility features in the framework.
While this change is unlikely to break any users in the wild, this is a
breaking change by the standards set out in our documentation and
should follow the breaking change announcement process. Details can be
found at https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes.
The error in question:
Missing concrete implementation of 'getter AccessibilityFeatures.onOffSwitchLabels' • packages/flutter_test/test/window_test.dart:252:7 • non_abstract_class_inherits_abstract_member
This reverts commit d12f2a609635d18ee89547131ff0a11eca59266c.
This reverts commit 6ea69a0d4339dd153899bb6c299689f1dd43329d.
On top of the revert, it reverted a commit in the PR:
https://github.com/flutter/engine/pull/14024
This reverts commit ea67e5b0b930ebf552bc7dbd678a35ee6a129c39.
Constructing colors using `fromRGBO` should return the same values as the CSS
`rgba()` notation. rgba(0, 0, 255, 0.5) is the same as `#0000ff80`
However `fromRGBO` sometimes creates a color with an off-by-one alpha value:
expect(Color.fromRGBO(0, 0, 255, 0.5), Color(0x800000ff));
Expected: Color:<Color(0x800000ff)>
Actual: Color:<Color(0x7f0000ff)>
If we use `withOpacity` to create the same color, it returns the correct color:
expect(Color.fromRGBO(0, 0, 255, 1).withOpacity(0.5), Color(0x800000ff));
This should also be changed in lib/web_ui/lib/src/ui/painting.dart in a
followup change.
If the image is a cross-context image that might be read from the GPU thread
during onscreen rendering, then it is not safe to read it concurrently from
the IO thread as part of Image.toByteData.
If the GPU thread does not have a graphics context, then fall back to
converting the image on the IO thread.
Fixes https://github.com/flutter/flutter/issues/30697
