Context:

The backdrop was added a couple of years ago per UX request. Omri, let me know if you want to change the behavior.

.. and ARC++ windows usually takes longer to change the state (to maximized state), which makes the backdrop more noticeable.

I'm assuming this could be an easy fix, wutao@ wdyt?

Are we doing something like below or remove the backdrop at all?

1. normal maximization: with black backdrop.
2. laptop to tablet transition: no black backdrop.

No black drop I assume, Ben?

Normal maximization backdrop is needed for the stretching effect we have. We shouldn't change that. 

| 1. normal maximization: with black backdrop.

As far as I know there's no black backdrop behind windows that are being normally maximized. That's the point of this bug. Please advise if this is not the case.

For pre-N apps we do have the black backdrop. See Spinly. 

I noticed there is one more case:

3. for non-maximized window in tablet mode, we will add black backdrop.

I see, yes, please retain whatever backgrounds are necessary for non-resizable apps. I'm curious if it's really necessary, though. In Canary laptop mode, what appears to be a non-resizeable window (because I get the prompt to restart) now smoothly animates after agreeing to the prompt - without a black background.

Yes, this bug is only about maximizing apps, apps that do not maximize obviously don't have an animation for maximizing so this shouldn't impact them :)

Ok, I've spoken with Sweet in person and I've cleared up my misunderstanding. There's a black background that's used for apps that are portrait locked - this fades in during normal maximization. I hope that from an implementation perspective that these are two different backdrops, but either way, we'll want to retain the backdrop for portrait locked apps.

The summary would be - retain any backgrounds that are necessary for things not to look broken or different than they do today in any resting state.

Remove any backgrounds that are just transient during maximize animations.

Please start background animation *after* maximize animation is completed.
We still need backdrop, as apps can be translucent, or ARC++ may not cover entire screen (and we can't guarantee 100% if it will or not in advance).

Starting backdrop animation when maximize animation starts (which can take a while for ARC++ apps) may actually be sufficient. I'd recommend to try this first.

Lots of work went in since Jannuary. Is this still needed?
Note: The application on top might - or might not be full screen. 

I guess what we should do instead is fading the layer in while doing the animation. Not sure if this is a problem for P - which we should check first.

Don't have a P device, but can still repro on 71.0.3544. Still needed.

Hi skuhne@, could you please help to find an owner for this bug? Thanks.