Fixes https://github.com/flutter/flutter/issues/124269
Manually verified this is safe on an iPhone 11.
We're not creating/encoding command buffers in this path so it's ok.
AFAICT the test I added would fail if we started doing that because it
doesn't provide any real command buffer interfaces. Most of the code
here is related to tests.
This PR makes view ID signed from unsigned int64.
Initially, I made view IDs unsigned because they were opaque anyway. As
I'm working deeper into multiview, I found some issues that made me
think signed is better:
* Unsigned integers are worse
* Sometimes you want negative values to represent special values.
* Unsigned integers are dangerous (if compared with signed ones by
mistake.)
* Unsigned integers are not needed
* We're very unlikely to reach that big anyway.
* Almost all other languages support only signed integers.
* Also JavaScript only supports up to 51 bits of integer.
Therefore I think it's better to change them to signed int64, especially
before these APIs are widely used by developers.
## Pre-launch Checklist
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I added new tests to check the change I am making or feature I am
adding, or Hixie said the PR is test-exempt. See [testing the engine]
for instructions on writing and running engine tests.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I signed the [CLA].
- [ ] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
These subclasses were previously made very generic to work with both the
pre-sk_sp version of SkFontMgr and the using-sk_sp version of SkFontMgr.
Now that SkFontMgr uses sk_sp for return types, simplify the subclasses.
Skia is changing SkFontMgr and SkFontStyleSet methods to consistently
return sk_sp<SkTypeface> and sk_sp<SkFontStyleSet> instead of
SkTypeface* and SkFontStyleSet*. The pointers returned always needed to
be SkSafeUnref'ed but with sk_sp this ownership is now explicit.
Flutter subclasses both SkFontMgr and SkFontStyleSet and overrides
affected methods. Normally Skia would roll out this change behind a
build flag which would first be set in Flutter (to hold out the change),
Skia then rolled into Flutter, then the build flag removed from Flutter
(along with updating the subclasses). However, this is made quite
difficult and slow because of the need to also be compatible with
Flutter in other repositories at the same time. Instead, this change
updates the subclasses to infer the correct return types in a way that
will work both with and without the Skia change. After the Skia change
is landed and rolled into Flutter the subclasses will be re-simplified
to match the new method signatures.
[0] https://skia-review.googlesource.com/c/skia/+/659856
Doing so is currently a NOP because `vm-service` isn't available in
flutter-release (aka Dart VM product) mode.
So this makes startup time of isolates slightly faster in
release mode and allows tree shaking of the relevant code in release
mode.
