Enable transparent FlutterViews

[mklim]

• Changes rasterizer to clear the canvas with SkColor_TRANSPARENT
• Removes the unused backgroundColor param from FlutterView.java

Partially addresses #9627

[chinmaygarde]

Can you verify this on iOS as well? Thanks.

[mklim]

Yes, verified on iOS too.

[matthew-carroll]

@mklim Maybe I already asked this, but why was the background color removed? You said it was unused but you removed code that reads the value from incoming attributes which means it may very well be used. Can you explain the thinking there? I have to make analogous changes within my refactor but I'm not sure we should have removed that.

[mklim]

@matthew-carroll

On it being unused: as far as I can tell the backgroundColor attribute was only ever read as a local variable in FlutterView.java's constructor. There was some logic there for falling back to a default if it was unset. (Formerly lines 131-138.) That local variable was then only ever used to pass into nativeSurfaceCreated, here. That call goes through the JNI layer to PlatformViewAndroid::SurfaceCreated. But backgroundColor wasn't actually being used anywhere in that method. So in the end none of the computations and calls up until that point mattered, and the attribute was ultimately unused.

I removed the code as a refactor while I was already going through these bits of code to work on the related AndroidView.java transparency. The combined defaulting-to-a-safe-color logic in AndroidView.java and the JNI call made it difficult to trace that backgroundColor wasn't really being used in the end and didn't affect anything. That's relevant for this bug since it could have theoretically been related: did AndroidView.java need to have a transparent backgroundColor in its layout file for transparency to work? Would having an explicitly opaque color as its attribute interfere with a transparent background set in the Flutter framework? In the end this had no effect at all, and removing this code meant removing that potential source of confusion.

[matthew-carroll]

So here are the lines in question:

    int color = 0xFF000000;
    TypedValue typedValue = new TypedValue();
    context.getTheme().resolveAttribute(android.R.attr.colorBackground, typedValue, true);
    if (typedValue.type >= TypedValue.TYPE_FIRST_COLOR_INT && typedValue.type <= TypedValue.TYPE_LAST_COLOR_INT) {
          color = typedValue.data;
    }

Notice that color may be set to typedValue.data, which comes from android.R.attr.colorBackground.

There are 2 questions I still think need to be answered:

1. Why isn't the above code considered a "use" of the background color? Am I misreading something?

2. At this point in time, given the change you merged, how would one give the FlutterView a background color before Flutter starts rendering? Are we saying that the only way to do that is to make it transparent and then set the background behind it? That might work for a number of cases, but might also be impossible for some unusual cases where there are other Views behind the FlutterView that would then show through.

So my thinking is that we should provide general support for a color. That color might be transparent, translucent, or opaque, and we should apply it accordingly. Any reason why that would be a problem?

[mklim]

1. Right, those are the former lines 131-138 I mentioned as having some safety checks and falling back to a default in my earlier comment. To try and clarify further, the "use" in those lines only existed to set the local variable int color. int color was then only used within AndroidView.java to set another local variable, final int backgroundColor, and then that was only ever used when it was passed to PlatformViewAndroid::SurfaceCreated through the JNI layer via the nativeSurfaceCreated method. PlatformViewAndroid::SurfaceCreated had a parameter for backgroundColor (linked above), but the parameter was never referred to or used in any way in the method body at all. So the attribute was ultimately unused to actually do anything, even though it was read in AndroidView.java and passed through the JNI. Does that make sense?

2. Right now (and before this deletion, since these deleted lines never actually affected anything), the color or transparency of a partial Android view is completely controlled by Flutter itself, not by the Android layout. If I'm remembering right for manual debugging I altered the main.dart of the flutter_view example (here) so that its only UI element was a Container with a color. I then could see that the color of the AndroidView was rendered correctly to whatever I put it in dart, and supported transparency (via setting the color to Colors.transparent). Unfortunately I don't still have that exact debugging code to show, but it should be easy enough to repro if you'd like.

I think the AndroidView layout attributes probably shouldn't control the background color, because then Flutter devs would need to tweak Android and iOS layout files individually for add-to-app scenarios instead of being able to control the entire thing from one place, within their main flutter UI layout. It seems like that would also introduce potential strange bugs where any one of the three conflicted.

[matthew-carroll]

Spoke offline.

The primary use-case in my mind is around splash color while Flutter is loading. I'm going to try to segment the API such that developers have splash color control, and then general transparency control for when Flutter is rendering, but we'll avoid supporting a general background color that goes from Android to Flutter.