This is not used anywhere in the engine. However, this API is easy to misuse as
one might incorrectly assume that it releases the reference on the underlying
object. Callers must use `reset` for this purpose.
Cleans up header order/grouping for consistency: associated header, C/C++ system/standard library headers, library headers, platform-specific #includes.
Adds <cstring> where strlen, memcpy are being used: there are a bunch of places we use them transitively.
Applies linter-required cleanups. Disables linter on one file due to included RapidJson header. See https://github.com/flutter/flutter/issues/65676
This patch does not cover flutter/shell/platform/darwin. There's a separate, slightly more intensive cleanup for those in progress.
We currently use a mix of C standard includes (e.g. limits.h) and their
C++ variants (e.g. climits). This migrates to a consistent style for all
cases where the C++ variants are acceptable, but leaves the C
equivalents in place where they are required, such as in the embedder
API and other headers that may be used from C.
Tweak the primary flutter build rule so that fuchsia is more similar to
other platforms in how tests and the shell are built.
Only embedder_unittests and GLFW tests are disabled on Fuchsia now.
TEST: Ran unittests on host/fuchsia; workstation on fuchsia
BUG: fxb/53847, fxb/54056
This change also adds TimeRecorder which records time at the start
of each frame to capture the latest vsync target display time and
wires it in to the rasterizer to add trace events when there is a lag.
This PR touches variable names, class names, and file names so it's significantly more risky than its predecessor https://github.com/flutter/engine/pull/17329
Due to file name changes, this PR is expected to change the license files.
We haven't rename `shell/gpu` to `shell/raster` yet. It should be optional but I think it's better to have `raster_surface_software.cc` than `gpu_surface_software.cc`.
Macros to control inlining are not used and we explicitly recommending against
playing with compiler inlining. The macros for alignment became part of the
standard in C++11 and we already use the standard variants over these macros
(see `PointerData`). The formatters are unused as well and we use the stream
based variants for formatting.
These should only be used on host binaries for more detailed crash reports.
Installing the handler on targets (iOS/Android) may cause use to break existing
crash reporting mechanisms users may have installed themselves in the process.
This should work on Darwin & Linux for now.
Doing something like int* a = nullptr; *a = 12; or abort or tripping an
assertion should print something the following before program termination. We
can tweak the report further if necessary.
```
[ERROR:flutter/fml/backtrace.cc(110)] Caught signal SIGSEGV during program execution.
Frame 0: 0x10658342c void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*)
Frame 1: 0x106555070 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*)
Frame 2: 0x106554f81 testing::Test::Run()
Frame 3: 0x106555dc3 testing::TestInfo::Run()
Frame 4: 0x1065570a1 testing::TestSuite::Run()
Frame 5: 0x106562a55 testing::internal::UnitTestImpl::RunAllTests()
Frame 6: 0x10658c22c bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*)
Frame 7: 0x1065625c3 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*)
Frame 8: 0x106562445 testing::UnitTest::Run()
Frame 9: 0x105c8dc33 RUN_ALL_TESTS()
Frame 10: 0x105c8dbe6 main
Frame 11: 0x7fff7c2dc3d5 start
```
Known issue: This routines that generate the stack trace are not signal safe.
But since we only use the same before the process is terminating, this ought to
be fine. I’ll work in a separate patch to convert all the internals to be signal
safe. In the meantime, this will help us better identify the causes of flakes on
our bots.
Fixes https://github.com/flutter/flutter/issues/50244
This reverts commit ef9e7b1a1365c07ab0df2e2016c4442c3963c2c7 with the following changes to accommodate an embedder for whom the original optimizations caused issues:
* Ensure stable order in the backing stores presented to the embedder. This is a pessimization that will be reverted when the embedder migrates. Tracked in https://github.com/flutter/flutter/issues/51228
* Forego the optimization where the unused layers would be collected before allocation of new layers needs to happen. This is a pessimization that will be reverted when the embedder migrates. Tracked in https://github.com/flutter/flutter/issues/51229
More context in b/146142979.
During the implementation of custom compositor integration, the embedder gets
callbacks on the render thread to prepare render targets (framebuffers,
textures, etc) for the engine to render into, callbacks to present these render
targets along with platform managed contents, and, callbacks to collect render
targets once they can no longer be recycled by the engine in subsequent frames.
During these callbacks, the engine mandates the OpenGL state on the render
thread be preserved. This restriction has been the source of hard to isolate
issues where the embedder trampled on the OpenGL bindings state in the callback
but failed to restore state before control went back to the engine. Due to the
nature of the OpenGL API, such errors are easy to make and overlook. This patch
lifts the restriction from the embedder. Embedders may now freely work with the
OpenGL state in custom compositor callbacks and the engine will make sure to
disregard OpenGL bindings when control flows back to it.
Disregarding current OpenGL state has a certain performance penalty and the
majority of this patch handles refactoring various engine embedder components
such that this happens only once per frame. The most trivial version of this
patch would reset context bindings on every transition of control flow from the
embedder to the engine. However, that naive approach would have necessitated
more than 50 binding resets in existing unit-test cases (depending on the number
of platform view interleaving levels and render target recycling hit rates). In
this implementation, bindings will be reset only once per frame and this does
not depend on the number of platform views in the scene.
The majority of this patch is a refactoring of engine subsystems used in
`ExternalViewEmbedder::SubmitFrame` which is thoroughly documented with each
opportunity for the embedder to invalidate OpenGL state tagged.
The refactoring also enables the implementation of the following optimizations
to engine behavior which should aid in reducing the memory needed for the
creation of render targets. These optimization include:
* The engine will only ask the embedder for render targets in which it expects
to render into. This was a quirk in the way in which root and non-root render
targets were handled. The engine could require the embedder to create a render
target but then realize it didn’t have anything to render into it. In the
presentation callback, it would skip that render target. But the embedder
still had to allocate that extra render target. This will no longer be the
case and should reduce memory use.
* The engine may now skip always realizing (via the embedder render target
creation callback) and presenting the root render target. This was also a side
effect of the same quirk. Previously, the engine would always ask the embedder
to present the root render target even if it was empty. Since this is no
longer the case, few render targets should be allocated which will reduce
memory consumption.
* The engine will now ask the embedder to collect unused render targets before
it asks it to create new ones. The previous behavior was to ask the embedder
for new targets and then collect old ones. This would cause spikes in memory
use when the size of the render targets would change. These memory use spikes
should now be troughs.
* The previous render target cache also considered the platform view ID in cache
viability considerations (instead of just the size of the render target). This
was a bug which has been fixed. This should lead to better cache utilization
in some situations.
These optimizations are now codified in unit-tests and the updated test
expectations are a result of these optimizations now being in place.
* Fixes https://github.com/flutter/flutter/issues/50751
* Fixes https://github.com/flutter/flutter/issues/46911
* Fixes https://github.com/flutter/flutter/issues/43778
* Fixes b/146142979
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.
