Enable Evas GL renderer for all profile #312
Conversation
JSUYA
force-pushed
the
dev/remove_evas_gl_only
branch
2 times, most recently
from
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)
| @@ -74,6 +81,8 @@ typedef struct { | |||
| // Array of Dart entrypoint arguments. This is deep copied during the call | |||
| // to FlutterDesktopRunEngine. | |||
| const char** dart_entrypoint_argv; | |||
| // The renderer type of the engine. | |||
| FlutterDesktopEngineRendererType renderer_type; | |||
There was a problem hiding this comment.
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.
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.
@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.
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.
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.
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.
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.
JSUYA
force-pushed
the
dev/remove_evas_gl_only
branch
from
f9a01c5
to
58e0549
Compare
JSUYA
force-pushed
the
dev/remove_evas_gl_only
branch
from
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 |
JSUYA
force-pushed
the
dev/remove_evas_gl_only
branch
2 times, most recently
from
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
JSUYA
force-pushed
the
dev/remove_evas_gl_only
branch
from
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)
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