fddb0ed30c
## Summary of the Pull Request Follow-up to #49633: replace the way the accent bar's first frame is protected. #49633 fixed the blank/stale first frame (#49489) by masking it — `Selector.Opacity = 0`, unveil after two `CompositionTarget.Rendering` ticks, backed by a 150 ms watchdog. This PR removes the cause instead, using the technique the Command Palette and Quick Access already ship: **DWM-cloak the overlay instead of hiding it**, so it never stops rendering and there is no stale frame to put back on screen. No user-visible behaviour change is intended beyond removing the fixed two-render-tick reveal delay; this is a mechanism swap plus the cleanup it enables. ## PR Checklist - [x] **Closes:** N/A — #49489 was already closed by #49633; this replaces that fix's mechanism - [x] **Communication:** follow-up to a merged PR in the same module, no new feature surface - [x] **Tests:** `PowerAccent.Core.UnitTests` 32/32 still pass (the pure width logic from #49633 is untouched). The current-head CI status is tracked in the PR checks; the compositor-specific manual measurements below were captured before the final commit-fence follow-up and are labeled accordingly - [x] **Localization:** no new end-user-facing strings - [x] **Dev docs:** N/A - [x] **New binaries:** none - [x] **Documentation updated:** N/A ## Detailed Description of the Pull Request / Additional comments ### Why cloaking A hidden WinUI 3 window renders nothing. Its composition surface therefore still holds the frame it was showing when it was hidden, and `ShowWindow` puts that stale frame back on screen before the rebuilt accent list has been laid out — that is #49489. Everything downstream of that follows from "the window does not render while hidden": * the bar cannot be measured before it is shown (a `Collapsed` subtree is never measured), hence #49633's measure-twice workaround; * #49633 deferred reveal using rendering ticks because it did not have a composition-commit fence; * this PR calls `Microsoft.UI.Composition.Compositor.RequestCommitAsync()` after the bar has been laid out, sized, positioned and scrolled, and only reveals after that commit completes. This replaces the frame counter and watchdog with an explicit compositor fence. A cloaked window is equally invisible to the user but stays `SW_SHOWNA`-shown, so XAML keeps laying it out and painting it. This is exactly what `Microsoft.CmdPal.UI\MainWindow.xaml.cs` does, and its comment names the same symptom: ```csharp // TRICKY: show our HWND again. This will trick XAML into painting our // HWND again, so that we avoid the "flicker" caused by a WinUI3 app // window being first shown ``` `QuickAccess.UI\QuickAccessXAML\MainWindow.xaml.cs` uses the same pattern, including the "warm up the window while cloaked" prewarm that this PR also picks up — which is what removes the *first summon of the process* case that #49633's second measurement existed for. ### What the summon looks like now `Show()` still raises `Showing`, so the surface leaves `Collapsed` and the bar lays out — but the window is still cloaked, so nothing reaches the screen. The bar is then measured **once** (on a templated, laid-out, non-collapsed subtree), sized, positioned and scrolled to the selection. The compositor commit is then awaited, and only after it completes does `Reveal()` uncloak the window. The first visible frame is a finished bar by construction rather than by timing. Removed as a result: `RevealTimeoutMs`, `FramesBeforeReveal`, `_revealTimer`, `_revealGeneration`, `_renderedFrames`, `_measuredContentWidthDip`, `ArmRevealTimeout`, `CancelPendingReveal`, `WaitForFirstFrameThenReveal`, `OnRenderingBeforeReveal`, the local `Reveal`, and the `Selector.Opacity` dance — 87 net lines out of `MainWindow`. `_showGeneration` stays: a layout callback queued by a dismissed summon still has to be dropped. ### `TransparentWindow` The cloak lives in the shared window because `Hide()` owns the `AppWindow.Hide()` that has to be replaced. It is **opt-in** (`EnableCloakedHide()`), so Shortcut Guide's overlay and CmdPal's toast keep hiding exactly as they do today; only Quick Accent enables it. `Reveal()` is a no-op for them. Two details worth review attention: * **Hit-testing.** Cloaking takes a window out of composition but *not* out of hit-testing, and this HWND sits exactly where the user is typing. While cloaked the window is therefore made click-through (`WS_EX_TRANSPARENT`), restored on reveal. Without this, an invisible accent bar would swallow clicks meant for the app underneath. * **`SW_HIDE` then `SW_SHOWNA`.** Same order as CmdPal: the hide is what hands the foreground back to whatever window should own it, and the show that follows leaves the window "shown" — which is what keeps XAML painting — while the cloak keeps it off screen. If DWM refuses to cloak, the HWND remains hidden; a later `Show()` retries instead of exposing an un-laid-out frame. ### Relationship to #34849 / #41044 Always-on-top is still released on hide, so the dormant overlay is `WS_EX_TOPMOST=False` exactly as before — verified below. Cloaking is orthogonal to topmost. The one honest trade-off is that the HWND is now permanently `WS_VISIBLE` (cloaked), so it keeps participating in composition while dormant, the same as CmdPal and Quick Access already do; it stays out of Alt-Tab and the taskbar via a hidden owner plus `WS_EX_TOOLWINDOW`. ## Validation Steps Performed > The build/test/live-state results below were recorded at `e372cdf`. Current head `ea658bb` adds the explicit `RequestCommitAsync` fence after that validation. Current-head CI is tracked by the PR checks, and the live window-state/frame-capture checks should be repeated before merge. * `build-essentials`, `Common.UI.Controls`, `PowerAccent.UI` and `PowerAccent.Core.UnitTests` all build clean (Debug|x64), 0 warnings. * `PowerAccent.Core.UnitTests`: 32/32 pass. * Live window-state measurement against the built `PowerToys.PowerAccent.exe` (`DwmGetWindowAttribute(DWMWA_CLOAKED)` + `IsWindowVisible` + ex-styles), driving a real summon of the <kbd>R</kbd> bar with **All languages** selected: | phase | state | |---|---| | dormant (prewarmed, before any summon) | `visible=True cloaked=1 topmost=False clickThrough=True` | | summoned | `visible=True cloaked=0 topmost=True clickThrough=False` | | dismissed | `visible=True cloaked=1 topmost=False clickThrough=True` | i.e. the window is shown-and-painting the whole time, invisible and click-through while dormant, and topmost/interactive only while summoned. * Screen-captured the summoned bar: all 22 characters for <kbd>R</kbd> render (including the wide `₹ ៛ ﷼`), leading and trailing padding are symmetric, nothing is clipped and the selection is on the first cell. --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Microsoft PowerToys
Microsoft PowerToys is a collection of utilities that help you customize Windows and streamline everyday tasks.
Installation · Documentation · Blog · Release notes
🔨 Utilities
PowerToys includes over 30 utilities to help you customize and optimize your Windows experience:
Advanced Paste
Always on Top
Awake
Color Picker
Command Not Found
Command Palette
Crop And Lock
Environment Variables
FancyZones
File Explorer Add-ons
File Locksmith
Grab And Move
Hosts File Editor
Image Resizer
Keyboard Manager
Light Switch
Mouse Utilities
Mouse Without Borders
New+
Peek
PowerDisplay
PowerRename
PowerToys Run
Quick Accent
Registry Preview
Screen Ruler
Shortcut Guide
Text Extractor
Workspaces
ZoomIt📦 Installation
For detailed installation instructions and system requirements, visit the installation docs.
But to get started quickly, choose one of the installation methods below:
Download the .exe file from GitHub
Go to the PowerToys GitHub releases, scroll down and select Assets to reveal the installation files, and choose the one that matches your architecture and install scope. For most devices, that would be x64 per-user.
Microsoft Store
You can easily install PowerToys from the Microsoft Store:
WinGet
Download PowerToys from [WinGet](https://github.com/microsoft/winget-cli#installing-the-client). Updating PowerToys via winget will respect the current PowerToys installation scope. To install PowerToys, run the following command from the command line / PowerShell:
- User scope installer (default)
winget install Microsoft.PowerToys -s winget
- Machine-wide scope installer
winget install --scope machine Microsoft.PowerToys -s winget
Other methods
There are [community driven install methods](https://learn.microsoft.com/windows/powertoys/install#community-driven-install-tools) such as Chocolatey and Scoop. If these are your preferred install solutions, you can find the install instructions there.
✨ What's new?
To see what's new, check out the release notes.
🛣️ Roadmap
We are planning some nice new features and improvements for the next releases – a brand-new Shortcut Guide experience, ensuring it's easier to find and install Command Palette extensions and so much more! Stay tuned for v0.100!
❤️ PowerToys Community
The PowerToys team is extremely grateful to have the support of an amazing active community. The work you do is incredibly important. PowerToys wouldn't be nearly what it is today without your help filing bugs, updating documentation, guiding the design, or writing features. We want to say thank you and take time to recognize your work. Your contributions and feedback improve PowerToys month after month!
Contributing
This project welcomes contributions of all types. Besides coding features / bug fixes, other ways to assist include spec writing, design, documentation, and finding bugs. We are excited to work with the power user community to build a set of tools for helping you get the most out of Windows. We ask that before you start work on a feature that you would like to contribute, please read our Contributor's Guide. We would be happy to work with you to figure out the best approach, provide guidance and mentorship throughout feature development, and help avoid any wasted or duplicate effort. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you grant us the rights to use your contribution and that you have permission to do so. For guidance on developing for PowerToys, please read the developer docs for a detailed breakdown. This includes how to setup your computer to compile.
Code of conduct
This project has adopted the Microsoft Open Source Code of Conduct.
Privacy statement
The application logs basic diagnostic data (telemetry). For more privacy information and what we collect, see our PowerToys Data and Privacy documentation.