-
Notifications
You must be signed in to change notification settings - Fork 6k
[Impeller] Flutter GPU: Add GpuContext. #44359
Conversation
lib/gpu/context.cc
Outdated
|
|
||
| std::string GpuContext::InitializeDefault(Dart_Handle wrapper) { | ||
| auto dart_state = UIDartState::Current(); | ||
| GpuContext::GpuContext(std::shared_ptr<impeller::Context> context) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Can the name of this class just be Context? Like the impeller:: counterpart?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
lib/gpu/context.dart
Outdated
| GpuContext? _defaultGpuContext; | ||
|
|
||
| /// Returns the default graphics context. | ||
| GpuContext getGpuContext() { | ||
| _defaultGpuContext ??= GpuContext._createDefault(); | ||
| return _defaultGpuContext!; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is equivalent to:
| GpuContext? _defaultGpuContext; | |
| /// Returns the default graphics context. | |
| GpuContext getGpuContext() { | |
| _defaultGpuContext ??= GpuContext._createDefault(); | |
| return _defaultGpuContext!; | |
| } | |
| final GpuContext gpuContext = GpuContext._createDefault(); |
As Dart static fields are already lazily evaluated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat! Done.
lib/gpu/context.dart
Outdated
|
|
||
| part of gpu; | ||
|
|
||
| class GpuContextException implements Exception { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: In general I would stick with the default Exception class unless you're adding way more details or you want to extensively document the circumstances under which a developer would catch GpuContextException over just a catch Exception
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed.
lib/gpu/context.dart
Outdated
| // Use of this source code is governed by a BSD-style license that can be | ||
| // found in the LICENSE file. | ||
|
|
||
| part of gpu; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the flutter gpu stuff is being developed as its own package, you don't necessarily need to use part/part of to force it into a single library. You can follow a regular import/export pattern like the framework does and it will just work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I keep going back and forth on this TBH. I really like the idea of importing one unit as gpu. Not married to it, though.
Maybe we can get the best of both worlds by structuring everything into separately importable files, but have an extra one that exports all of the others. I could do something like that in a follow-up. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can absolutely do that with regular libraries, see https://github.com/flutter/flutter/blob/master/packages/flutter/lib/widgets.dart
You would create a single flutter_gpu/lib/flutter_gpu.dart library that re-exports the types you want to be public from flutter_gpu/lib/src/**
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, should we be fully structuring this like a package in all respects, with a lib directory and a pubspec.yaml that specifies the flutter SDK as a dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally yes - Do you depend on the flutter_sdk (package:flutter) or do you depend on dart:ui?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, I meant sky_engine in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, in that case I would add the following to the pubspec :
sky_engine:
sdk: flutter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reworked it to as an actual package and changed the import scheme.
c40ac50 to
5c49f37
Compare
lib/gpu/context.dart
Outdated
| /// A handle to a graphics context. Used to create and manage GPU resources. | ||
| /// | ||
| /// To obtain the default graphics context, use [getContext]. | ||
| class Context extends NativeFieldWrapperClass1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should retain GpuContext for this class. Dart itself does not have namespaces, and namespaced imports import "package:flutter_gpu/flutter_gpu" as gpu are uncommon.
Context will commonly collide with other Context types, forcing developers to add import namespaces to disambiguate which will be annoying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Done.
Co-authored-by: Jonah Williams <[email protected]>
Co-authored-by: Jonah Williams <[email protected]>
jonahwilliams
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…132108) flutter/engine@c271092...9c83d90 2023-08-07 [email protected] Roll Dart SDK from 0816d590a220 to f664f4b9c50d (1 revision) (flutter/engine#44462) 2023-08-07 [email protected] [Impeller] Flutter GPU: Add GpuContext. (flutter/engine#44359) 2023-08-07 [email protected] Fix use-after-free crash in glfw embedder (flutter/engine#44358) 2023-08-07 [email protected] Roll Skia from 9fbd7296de9a to d1ada6624536 (1 revision) (flutter/engine#44447) 2023-08-07 [email protected] Revert clang back to 6d667d4b261e81f325756fdfd5bb43b3b3d2451d (flutter/engine#44442) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC [email protected],[email protected],[email protected] on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Move the GpuContext to its new home. I added a `flutter_tester` test that just verifies an exception is gracefully thrown when Impeller isn't available. In a later patch, I'll land a way to eagerly supply the Impeller context on the cpp side to enable testing through the playground (as mentioned in flutter/flutter#127712).
Move the GpuContext to its new home. I added a
flutter_testertest that just verifies an exception is gracefully thrown when Impeller isn't available.In a later patch, I'll land a way to eagerly supply the Impeller context on the cpp side to enable testing through the playground (as mentioned in flutter/flutter#127712).