Welp. I'll let Owen look into this one. We currently didn't do this for performance reasons. Drawing ten shadows at 60 frames per second isn't really the best way to get smooth animations, and we're not sure that downscaled shadows would look good either.

The obvious thing to do on this bug would to make the windows in the overview clones of the entire window actor (which includes the shadow) rather than just of the texture holding the window contents.

This will have two problems:

 * It's not going to look right. Since different window actors are scaled
   by different amounts, the shadows for different windows will have
   different effective blur-amounts and offsets. So they'll look like they
   are different heights.

 * It's going to be slow when going into the overview. To make shadows 
   perform in the normal view, we count heavily on the visible region
   optimizations so that we only draw the small amount of the shadow
   peaking out from under the window. We turn these optimizations
   off as soon as we transform windows - like we do when entering the
   overview. So we'd be alpha-blending a gigantic big shadow under
   each window we draw for intermediate frames.

My suggestion for something that might work would be instead of using the exact shadow textures that mutter computes for each window, use a single MetaShadow that is created for a generic rectangle - this will allow us to draw a correct shadow for any sized rectangle - and the windows in the overview are closer to rectangles than their unscaled versions unless they are actually shaped clocks or something. (Omit shadows for shaped clocks...)

Since the shadows will scale down with the actors while fading in and become smaller and darker as the actors go into the final position, the effect will probably look like the windows are settling down onto the overview - which might look right or 

The simple thing to do is to keep using clones of the window texture and then add a MetaShadowActor that encapsulates a MetaShadow and draws with it, and then just stack them.

The alternate would be to pursue bug 678989 and have

    let w = new Meta.WindowActor({ meta_window: my_meta_window, 
                                   shadow_class: 'overview-shadow',
                                   rectangular_shadows: true,
                                   shadow_opacity: 0 });
    stage.add_actor(w);

And tween shadow opacity to 1 only over the end of the animation to the overview.

(The current patch in bug 678989 needs substantial work and there are quite a few open questions, but the idea of dropping the use of clones is doable.)

That would make the highlighting frame around the selected window in the overview even harder to see

GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.