flutter-tizen / engine

The Flutter engine
https://flutter.dev
BSD 3-Clause "New" or "Revised" License
6 stars 19 forks source link

Blank screen is displayed when launching app on Evas GL #222

Closed bbrto21 closed 1 year ago

bbrto21 commented 2 years ago

Originally posted at : https://github.com/flutter-tizen/plugins/pull/266 by @swift-kim

Even without splash screen, when launching app newly on wearable, a blank screen is displayed once for a while. If you set elm_win_alpha_set as a true, it may seem to be solved, but it is not right to always treat it as transparent(This may affect performance badly).

Related discussions

bbrto21 commented 2 years ago

I guess that Flutter view of other platforms provide a method to notify first frame rendered

JSUYA commented 2 years ago

HI @bbrto21 I saw this problem and made a sample based on my ideas. https://github.com/flutter-tizen/plugins/pull/266 This PR was a way to register splash image in dart code.

In the evas_gl scenario, we can put a splash image in advance before setting the gl surface in evas_image. After that, when the first frame of the flutter is drawn, we can set the gl surface to evas_image.

I made a sample based on this idea. But I couldn't figure out when the first frame of the flutter was drawn. So, when TizenRenderEventLoop's callback is called, I skipped the first call and set the gl surface when the second callback was called. (Of course, this is a just trick.)

I want to know when the first frame of the flutter is rendered. can you tell me about this?

flutter-splash-test

seungsoo47 commented 2 years ago

@JSUYA It's an good approach. I have a question for the splash image. If the splash image is always set before the first frame, can application developers change it later? I just wonder if it's possible because they might think that they want to set up a splash image for their company.

swift-kim commented 2 years ago

@seungsoo47 Am I understanding you correctly? A splash screen is configured by an app developer (in tizen-manifest.xml) when building their app.

seungsoo47 commented 2 years ago

@JSUYA @swift-kim Oh~ I am sorry. It was my misunderstanding. Please ignore my question.

JSUYA commented 2 years ago

@swift-kim I do not know yet how to get the information of tizen-manifest.xml set in application from flutter-tizen. um.. I think, we can add splash image path to FlutterDesktopEngineProperties. (maybe?) anyway the basic idea of my opinion is to pre-set the image to evas_image before drawn flutter's first frame.

swift-kim commented 2 years ago

@JSUYA Oh, then you're not going to use Tizen's built-in splash screen feature? Hmm. That could be a good option. We might provide an API (such as FlutterApp.SetSplashImage()) in our embedding so that users can set splash image paths in their C++/C# code. A fun fact is that Android Flutter apps used to support a similar functionality through the provideSplashScreen interface but the Flutter team is now deprecating the API.

bbrto21 commented 2 years ago

Recently, a patch that seem useful to solve this on the upstream side have been merged.

swift-kim commented 1 year ago

@bbrto21 I made an attempt by cherry-picking the patch but failed (the app window didn't show up after launch).

https://github.com/swift-kim/embedder/commits/next-frame-callback

The code defers calling TizenWindow::Show() until the engine is ready to draw a frame and explicitly schedules a frame after the engine is started. I'm not sure why this doesn't work. Am I doing right or did you mean something different?

bbrto21 commented 1 year ago

@swift-kim Thanks for attempting. I took a look at what you tried but this only works properly when the FlutterRendererType is EGL. otherwise, the NextFrameCallback wasn't even called. I think we missed something. :cry:

swift-kim commented 1 year ago

I tried running the next frame callback from the platform thread without success. (The commit is available in the branch linked above.) The problem is that the embedder API callback itself (FT_LOG(Error) and PostTask in the code) is not being called, so threading has nothing to do with this issue.