Skip to content

Acrylic effect in Windows 10 20H1 Search Window

krlvm edited this page Jul 8, 2021 · 2 revisions

The built-in Search Window Acrylic effect is broken in Windows 10 20H1+ builds, but BeautySearch has an alternative solution - it makes screenshot of your desktop and captures the rectangle behind the Search Window which is used as a background with blur filter applied. Fake acrylic effect does not react to changes under the window and always looks the same. You need to reinstall BeautySearch every time you changed the wallpaper to make it look consistent. You can always replace it manually - it is located in C:\Windows\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\cache\Local\Desktop\background.png. Stop SearchApp.exe process or reboot to apply changes.
Note: The Fake Acrylic effect is the same for all users of the system, regardless of the wallpaper.


Here's some technical information collected by me, for those who want to try to fix it with their own hands.
partially translated by machine translation

Search Window Acrylic effect was introduced in Windows 10 19H1 as a part of UI redesign and separating Search Application from Cortana, but it does not work since Windows 10 version 20H1 aka May 2020 Update (build number 19041). To be precise, the last version of 20H1 to support Acrylic in Search Window was Build 18965 and it was broken in Build 18970 most likely in the process of completely separating the Search from Cortana - Search Application in 19H1 was called SearchUI and was renamed to SearchApp in 20H1.

Like 19H2, 20H2, 21H1, 21H2 and, most likely, all subsequent builds of Windows 10, due to the announcement of Windows 11, are just enablement packages based on version 20H1. This was not an intended change and was fixed in Insider Build 19541 which was released in January, 2020, but the fix still haven't backported to public Windows 10 builds, and, most likely, will be gone.

If you press Win + S (the keyboard shortcut to open the search) very quickly, you will notice that before the start of the animation of the search window, a white or black surface appears under it, depending on the selected theme, which was not the case in previous versions. You can change the theme of Windows elements from dark to light or vice versa and notice this surface due to the contrast. As I was able to find out, this surface has always been, but in previous versions it was completely transparent. Again, by changing the theme, you will notice that the window itself has slightly changed color. Just because the Acrylic effect hasn't gone anywhere, the acrylic brush is right under the EdgeHTML WebView, but it rests against this opaque surface - you can check this in the Visual Studio Live Visual Tree by attaching debugger to process SearchApp.exe. After hiding all the elements, only the very surface remains, which is actually the background of the window. You will not be able to view the properties of any UWP window through the Live Visual Tree, but it is possible to do this through the Win32 API.

News and Interests introduced in 21H1 - this is also a part of SearchApp.exe, however, this bug is not there, since the mechanics of this window are different from the Search Window - it is identical to the mechanics of the calendar and other flyouts - it is not the content that slides over the surface, but the surface itself i.e. the window, therefore, unlike the Search Window, it reacts to disabling animation in the classic advanced system settings. Unlike the Search Window and Action Center, the shadow does not appear abruptly after the animation ends. If you collapse all the elements using VS Live Visual Tree you will see a completely transparent window with border shadow.

As soon as the background of the window becomes completely transparent, the acrylic effect will return, but for UWP this is not so easy to do, so here you need to have a lot of experience with WinAPI or know some undocumented DWM functions (this is definitely not SetWindowCompositionAttribute). Such a breakdown during development could just cause a bug.

Clone this wiki locally