-
Notifications
You must be signed in to change notification settings - Fork 17
Enable Evas GL renderer for all profile #312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable Evas GL renderer for all profile #312
Conversation
3e321dd to
f9a01c5
Compare
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312)
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312)
| // to FlutterDesktopRunEngine. | ||
| const char** dart_entrypoint_argv; | ||
| // The renderer type of the engine. | ||
| FlutterDesktopEngineRendererType renderer_type; |
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.
Please consider moving this property to FlutterDesktopView(Window)Properties since it's not relevant for headless engine. You will need to refactor the code a little bit, for example,
- Move the renderer initialization code from
FlutterTizenEngine's constructor to a separate method and call it fromFlutterTizenView'sSetEngineorCreateRenderSurface, or - Let
FlutterTizenViewown the renderer instance.
Note: event_loop_ and render_loop_ can be initialized during RunEngine.
Does this make sense? Do you have any thought? @bbrto21
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.
How about adding a None type in Type for headless?
I can move the renderer to FlutterTizenView as you said.
However, when FlutterEngine used in flutter-tizen, I think that if we create a renderer in the engine, it can be helpful for improvement of the launch time(?).
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.
@swift-kim I think it make sense. all task runners are needed at the time of the run engine, so you can initialize them lazily.
The renderer depends on what the view is. So I think it's fair to associate renderer with view.
If the engine has a specific type of renderer, the available views are limited by that type.
So it seems more flexible and simpler for user to deal with the type of view in the API, not the renderer type.
Well, one more thing, I think adding a renderer type to the member of a flutter project is also a little inappropriate.
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 guys are right. This way is a problem because the render type must be set when creating a FlutterEngine for ElmFlutterView.
I will move this to the view. I think there will be more code changes...
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.
Is the renderer_type property only applicable to FlutterDesktopWindowProperties? How about FlutterDesktopViewProperties?
Regarding the launch time optimization, maybe we could remove RunEngine from the FlutterDesktopViewCreate family and provide another API that starts the engine associated with a view.
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 might take renderer_type as an argument of FlutterDesktopViewCreateFromNewWindow or FlutterDesktopViewCreateFromElmParent if you don't want to add the property to both structs.
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 added renderer_type only to FlutterDesktopWindowProperties. I didn't add it to FlutterDesktopViewProperties because for now only EvasGL is used. We can add them later if needed.
f9a01c5 to
58e0549
Compare
58e0549 to
51c26a5
Compare
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312)
|
https://github.com/flutter-tizen/engine/runs/7334808882?check_suite_focus=true#step:6:53 |
e378ecf to
1e98c05
Compare
For devices other than wearable, we can either use ElmFlutterView or EcoreWl2Window, depending on apps. This commit is to avoid being device dependent. Remove the build flag for evas_gl only and use the WEARABLE_PROFILE macro if necessary. Before creating the engine, the embedding can select the renderer type in the engine property. On runtime, it selects an appropriate renderer and external texture according to the renderer type and renders it. related issue : flutter-tizen#301
1e98c05 to
d06b6fa
Compare
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312)
swift-kim
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.
Only minor concerns. Otherwise looks good to me!
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312) Remove renderer type in engine properties If profile is wearable, the default of renderer type is kEvasGl Add profile check for renderer in C# Add profile check for renderer in cpp fix package test Apply review comments Change file mode
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312) Remove renderer type in engine properties If profile is wearable, the default of renderer type is kEvasGl Add profile check for renderer in C# Add profile check for renderer in cpp fix package test Apply review comments Change file mode
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312)
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312) Remove renderer type in engine properties If profile is wearable, the default of renderer type is kEvasGl Add profile check for renderer in C# Add profile check for renderer in cpp fix package test Apply review comments Change file mode
Set the renderer type before creating the engine. The window is selected as EcoreWl2 or ElmWin according to the renderer type. This commit requires engine side commits. (flutter-tizen/engine#312)
For devices other than wearable, we can use either ElmFlutterView or EcoreWl2Window, depending on apps. This commit is to avoid being device dependent. Remove the use_evas_gl_renderer build flag and use the WEARABLE_PROFILE macro if necessary. Before creating the engine, the embedding can select the renderer type in the engine property. At runtime, it selects an appropriate renderer and external texture according to the renderer type and renders to it.
For devices other than wearable, we can use either ElmFlutterView or EcoreWl2Window, depending on apps. This commit is to avoid being device dependent. Remove the use_evas_gl_renderer build flag and use the WEARABLE_PROFILE macro if necessary. Before creating the engine, the embedding can select the renderer type in the engine property. At runtime, it selects an appropriate renderer and external texture according to the renderer type and renders to it.
For devices other than wearable, we can either use ElmFlutterView or EcoreWl2Window,
depending on apps. This commit is to avoid being device dependent.
Remove the build flag for evas_gl only and use the WEARABLE_PROFILE macro if necessary.
Before creating the engine, the embedding can select the renderer type in the engine property.
On runtime, it selects an appropriate renderer and external texture
according to the renderer type and renders it.
related issue : #301