- 24 3月, 2020 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 23 3月, 2020 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 17 3月, 2020 1 次提交
-
-
由 gaaclarke 提交于
-
- 11 3月, 2020 1 次提交
-
-
由 Chinmay Garde 提交于
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
-
- 25 2月, 2020 1 次提交
-
-
由 Chinmay Garde 提交于
Reland "Lift restriction that embedders may not trample the render thread OpenGL context in composition callbacks." (#16711) This reverts commit ef9e7b1a 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.
-
- 19 2月, 2020 2 次提交
-
-
由 Chinmay Garde 提交于
Revert "Lift restriction that embedders may not trample the render thread OpenGL context in composition callbacks. (#16653)" (#16674) This reverts commit 110c1c9a.
-
由 Chinmay Garde 提交于
Lift restriction that embedders may not trample the render thread OpenGL context in composition callbacks. (#16653) 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
-
- 07 2月, 2020 1 次提交
-
-
由 George Wright 提交于
-
- 06 2月, 2020 2 次提交
-
-
由 stuartmorgan 提交于
A number of POSIX methods were renamed on Windows to match standards requirements, giving deprecation warnings when calling strdup on Windows. This adds a wrapper, to allow calling _strdup on Windows instead. Part of #16256
-
由 stuartmorgan 提交于
Targeted suppression of some deprecation warnings that are build errors under clang: - Ignore the deprecation of codecvt's unicode conversion until we decide on a replacement strategy. - Allow the deprecated posix names of functions in third_party/txt. Part of https://github.com/flutter/flutter/issues/16256
-
- 04 2月, 2020 1 次提交
-
-
由 Chinmay Garde 提交于
Investigation is being tracked in https://github.com/flutter/flutter/issues/50032.
-
- 01 2月, 2020 1 次提交
-
-
由 Chinmay Garde 提交于
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.
-
- 24 1月, 2020 1 次提交
-
-
由 George Wright 提交于
-
- 22 1月, 2020 1 次提交
-
-
由 Nathan Rogers 提交于
When running on Fuchsia, respect the argument values that Skia passes into the Flutter implementation of the |SkEventTracer| interface. Bug: https://github.com/flutter/flutter/issues/48864
-
- 20 12月, 2019 1 次提交
-
-
由 George Wright 提交于
-
- 04 12月, 2019 4 次提交
-
-
由 David Worsham 提交于
-
由 Kaushik Iska 提交于
This reverts commit 6c605f8a.
-
由 David Worsham 提交于
-
- 28 11月, 2019 1 次提交
-
-
由 David Worsham 提交于
-
- 27 11月, 2019 1 次提交
-
-
由 Chinmay Garde 提交于
The converters are still in a separate target that must be included manually. This allows targets that depend on FML but not Dart runtime not have to depend on the runtime. Adds a test that includes this target and tests image decompression from assets. There is also a test for the standalone DartConvertor in shell_unittests but not in fml_unittests be cause FML uni-tests cannot yet launch a VM. I will work on adding fixtures for those.
-
- 26 11月, 2019 1 次提交
-
-
由 David Worsham 提交于
* Add fuchsia MessageLoopImpl; fix several tests
-
- 23 11月, 2019 1 次提交
-
-
由 gaaclarke 提交于
-
- 07 11月, 2019 1 次提交
-
-
由 George Wright 提交于
Add fml_tests target for the fml unit tests on Fuchsia
-
- 17 10月, 2019 1 次提交
-
-
- 23 8月, 2019 1 次提交
-
-
由 Kaushik Iska 提交于
The core underlying issue is that vector push_back could re-allocate and cause us to segfault. I have switched the backing queues to a map per @jason-simmons suggestion in flutter/flutter#38778. I've also added a test to capture the aforementioned bug. I've run internal tests several times to validate that this is fixed. General threading note for this class is that only the following operations take a write lock on the meta mutex: 1. Create 2. Dispose The rest of the operations take read lock on the meta mutex and acquire finer grained locks for the duration of the operation. We can not grab read lock for the entire duration of NotifyObservers for example because observer can in-turn create other queues -- Which we should not block. Additional changes: 1. Make as many methods as possible const. Unlocked methods are all const. 2. Migrate all the queue members to a struct, and have a map. 3. Get rid of the un-used Swap functionality.
-
- 13 8月, 2019 1 次提交
-
-
由 Kaushik Iska 提交于
After pre-roll we know if there have been any mutations made to the IOS embedded UIViews. If there are any mutations and the thread configuration is such chat the mutations will be committed on an illegal thread (GPU thread), we merge the threads and keep them merged until the lease expires. The lease is currently set to expire after 10 frames of no mutations. If there are any mutations in the interim we extend the lease. TaskRunnerMerger will ultimately be responsible for enforcing the correct thread configurations. This configuration will be inactive even after this change since still use the same thread when we create the iOS engine. That is slated to change in the coming PRs.
-
- 06 8月, 2019 1 次提交
-
-
由 Nathan Rogers 提交于
When |OS_FUCHSIA| is defined (even when |FUCHSIA_SDK| is defined as well), use the Fuchsia SDK trace macros rather than the Dart timeline. Reasons for doing this include: Fuchsia's trace macros support categories. This allows one to distinguish between (e.g.) "flutter" and "skia" trace events for trace recording and trace visualization. Fuchsia has existing in tree benchmarks that depend on finding certain events under category "flutter". See the Fuchsia performance mailing list discussion for more context.
-
- 13 7月, 2019 1 次提交
-
-
由 Kaushik Iska 提交于
- Add the functionality to merge and unmerge MessageLoopTaskQueues This introduces a notion of a "owning" and "subsumed" queue ids. Owning queue will take care of the tasks submitted to both that and it's subsumed queue. - The tasks submitted still maintain the queue affinity - Same for the task observers - Also adds MergedQueuesRunner which grabs both the locks owner and subsumed queues in RAII fashion. - Also use task queue id to verify if we are running in the same thread. - This is to enable merging the backed message loop task queues to enable dynamic thread merging in IOS.
-
- 11 7月, 2019 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 20 6月, 2019 1 次提交
-
-
由 Kaushik Iska 提交于
-
- 14 6月, 2019 2 次提交
-
-
由 Kaushik Iska 提交于
* Refactor to move Task Queue to its own class - This is to help with sharing task queue among multiple message loops going forward. - currently there is 1:1 mapping between task queue and message loop, we are still maintaining the semantics for this change. * Add mutex include * Most of the waking up changes minus test failures * Refactor MessageLoopImpl to be Wakeable - Makes testing easier by letting us putting a TestWakeable - Also move the waking up logic to the task queue * add tests * Fix formatting and license
-
由 Kaushik Iska 提交于
* Refactor to move Task Queue to its own class - This is to help with sharing task queue among multiple message loops going forward. - currently there is 1:1 mapping between task queue and message loop, we are still maintaining the semantics for this change. * Add mutex include * Add unit tests for task queue * fix formatting * license
-
- 12 6月, 2019 1 次提交
-
-
由 Kaushik Iska 提交于
* Refactor Delayed Tasks to their own class * fix some comments * Update BUILD.gn
-
- 29 5月, 2019 1 次提交
-
-
由 Chinmay Garde 提交于
* Allow specifying both Dart and non-Dart fixtures in engine unittests. This fixes numerous issues in the way in which fixtures were managed in the engine unit-tests. * Instead of only being able to specify Dart fixtures, unit-tests may specify non-Dart fixtures as well. These are simply copied over to the fixtures directory known to the unit-test at runtime. * An issue where numerous Dart files could be given to the kernel snapshotter has been addressed. It was anticipated that such a (legal) invocation to the kernel snapshotter would produce a snapshot with the contents of all the Dart files added to the root library. This is incorrect and the behavior in this case is undefined. * Dart files referenced by the main Dart file are correctly tracked via a depfile. * The snapshotter arguments have been cleaned up to get rid of unused arguments (`—strong`) and the use of the VM product mode argument has been corrected to no longer depend on the Flutter product mode.
-
- 16 5月, 2019 1 次提交
-
-
由 Matthew Dempsky 提交于
This is forward compatible with std::size and similar to how Chromium removed use of the arraysize macro.
-
- 14 5月, 2019 1 次提交
-
-
由 Chinmay Garde 提交于
-
- 07 5月, 2019 1 次提交
-
-
由 Chinmay Garde 提交于
This does not actually import the runners into the engine. It only sets up the targets so they need no modifications are necessary when the migration is done. The engine has been verified to build in both buildroots.
-
- 27 4月, 2019 1 次提交
-
-
由 Dan Field 提交于
-
- 10 4月, 2019 1 次提交
-
-
由 Chinmay Garde 提交于
When flutter/synchronization was first authored, we did not own fml (it was called fxl then). Now we do, so use a single spot for such utilities. The pipeline was meant to be a general purpose utility that was only ever used by the animator (it even has animator specific tracing), so move that to shell instead (where the animator resides).
-