Allow FlutterViewController to specify whether its FlutterView is opaque

[dnfield]

Fixes flutter/flutter#21808

We set CAEAGLLayer.opaque to YES today, which follows Apple's recommendations for performance. We don't do this when we're just using a CALayer for software rendering. This means that an Add2App consumer will see their view as transparent on the simulator but opaque on a real device, and they have no way to change that behavior on device (or on the Simulator for that matter).

This patch makes the behavior consistent on simulator/device (which is technically breaking change for simulator builds), and allows Add2App consumers to specify whether the view should be opaque or not as a property on FlutterViewController.

Two questions:

1. Would be safe to cache the result of [FlutterView flutterViewController]? It now will potentially be called more frequently and is called for each call to drawLayer - which could potentially save us a few isKindOfClass checks. Removing this method altogether and replacing with a delegate
2. We have this functionality on the Android side, but are we going to enable developers to shoot themselves in the foot by degrading performance for this? Yes, this isn't free, but it has some important use cases (such as showing a FlutterViewController over another screen, and avoiding a flicker of content when loading a FlutterViewController).

/cc @cbracken @matthew-carroll @amirh (FYI)

[jamesderlin]

Is there a desire to be able to dynamically set a FlutterView from opaque to transparent (or vice-versa)? If not, then couldn't you avoid [self flutterViewController] by having the FlutterViewController initialize FlutterView with the desired opaqueness?

[dnfield]

That's a good point. the way it's implemented right now, changing this wouldn't dynamically change the FlutterView until a relayout happened (e.g. changing screen orientation or resizing the view).

I think if we went the route you're suggesting, I'd rather have this be an initializer parameter on FlutterViewController as well though, as the property form of it would become even more confusing in that context. That said, I think having it as an initializer parameter might make more sense anyway.

[dnfield]

Trying to figure out if/how any of this impacts storyboard usage.

[dnfield]

Another option (which might allow for more natural iOS programming) is to have an initializer parameter that says whether the FlutterView automatically sets this at all. I'm not really sure why we'd need to set this repeatedly on layoutSubviews.

[dnfield]

I'm now passing the FlutterViewController as a WeakPtr into the FlutterView initializer. I've also wired the property so we can do this dynamically, as @matthew-carroll pointed out we might want to do this when initially loading the view to avoid a flash of content.

[jamesderlin]

"accelleration" => "acceleration"

[jamesderlin]

initWithDelegate (and elsewhere)

[jamesderlin]

Do you plan to use this elsewhere? If not, it's clear to me what advantage this provides over passing the FlutterViewController down directly like you did in the previous version.

[dnfield]

No, but it feels pretty wrong to pass a view controller directly into a view. I was looking at passing in just the shell, and after discussion with @chinmaygarde decided to go with a delegate - this way we avoid trying to share a pointer to the shell, and we avoid tying the ViewController implementation details to the View.

[jamesderlin]

LGTM, but you probably should get a review from Chinmay too.

[chinmaygarde]

Nit: @property(nonatomic, getter=isViewOpaque) BOOL viewOpaque; with the setter being inferred as setIsOpaque is more idiomatic. See -[UIView opaque] for another such use.

[dnfield]

Done

[lenaschimmel]

Thanks for your patch / PR, @dnfield! I thought this would be the solution to use native map views on iOS in my flutter app.

I just tried it, and it did not work exactly as I hoped. Not sure if this is a bug of if I misunderstood how it should be used.

In the simplest test case without a map, I used the default Runner app and modified it. I made a custom ViewController class, extended FlutterViewController and in my init methods I do

    self.isViewOpaque = false;
    self.view.backgroundColor = UIColor.red;

after calling the super.init() method. When I run it on a device, I can see the native red background behind my Flutter widgets. But flutter redraws the widgets, the old rendering is still there and will be overdrawn. I can see this when a widget moves, but also the "debug" badge in the upper right corner will be drawn upon its previous rendering, making the drop shadow darker and darker each time.

I guess the FlutterView would need to somehow clear its surface before drawing once again, and I think this should be the default behavior when viewIsOpaque is false. (Clearing would only be redundant if the FlutterView has binary transperency, i.e. no semi-transparent pixels, and no opaque pixel ever becomes transparent. I think this is an edge case, not a sensible default.)

The same happens if I actually put a map view underneath the flutter view (I tried Map Kit and MapBox). The map is animated properly and I can see it through the FlutterView, but Flutter Widgets leave trails behind when they move.

Is this understandable, or do you need a screen shot?

[amirh]

Hi Lena, I believe I the issue you are describing is fixed in #6753

…

On Wed, Nov 7, 2018 at 6:21 AM Lena Schimmel ***@***.***> wrote: Thanks for your patch / PR, @dnfield <https://github.com/dnfield>! I thought this would be the solution to use native map views on iOS in my flutter app. I just tried it, and it did not work exactly as I hoped. Not sure if this is a bug of if I misunderstood how it should be used. In the simplest test case without a map, I used the default Runner app and modified it. I made a custom ViewController class, extended FlutterViewController and in my init methods I do self.isViewOpaque = false; self.view.backgroundColor = UIColor.red; after calling the super.init() method. When I run it on a device, I can see the native red background behind my Flutter widgets. But flutter redraws the widgets, the old rendering is still there and will be overdrawn. I can see this when a widget moves, but also the "debug" badge in the upper right corner will be drawn upon its previous rendering, making the drop shadow darker and darker each time. I guess the FlutterView would need to somehow clear its surface before drawing once again, and I think this should be the default behavior when viewIsOpaque is false. (Clearing would only be redundant if the FlutterView has *binary transperency*, i.e. no semi-transparent pixels, and no opaque pixel ever becomes transparent. I think this is an edge case, not a sensible default.) The same happens if I actually put a map view underneath the flutter view (I tried Map Kit and MapBox). The map is animated properly and I can see it through the FlutterView, but Flutter Widgets leave trails behind when they move. Is this understandable, or do you need a screen shot? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6570 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-gdX2z7h4uidj_2qn4SDlrLkvWDSKJks5usuxugaJpZM4Xk32D> .

[lenaschimmel]

Thanks for the very quick answer, @amirh, it was indeed fixed in #6753.

It took me some time to test it, because the change is not yet in the dev channel and I didn't know that I can also do flutter channel master. It works great!