• Thread Author

Tech detective or headline shorthand? Here’s what’s actually changing under the hood — and what you can do about it.
A popular write‑up on Touch Reviews summarizes a claim by a tech creator (named in that piece as “epcidiy”) that Windows 11’s perceived sluggishness — slow right‑click menus, laggy File Explorer, slower Task Manager — comes down to Microsoft moving large parts of the shell to modern XAML/WinUI code and (reportedly) using so‑called “XAML islands.” The article frames that as a simple trade‑off: prettier UI in exchange for responsiveness. The core idea has merit, but the reality is more nuanced. Below I unpack the technical facts, validate them against Microsoft and independent sources, point out where the Touch Reviews piece appears to conflate or misname technologies, and give a practical troubleshooting checklist for users who want immediate relief.
Summary — the simple takeaways
  • The phrase “XML islands” in the Touch Reviews piece is almost certainly a typo / confusion. The relevant Microsoft technology is called XAML Islands (or simply XAML / WinUI in many places). Microsoft documents XAML Islands and how they host XAML UI inside native (Win32/WPF) apps. (learn.microsoft.com)
  • Microsoft has been modernizing parts of the Windows shell (notably File Explorer and other system apps) using the Windows App SDK / WinUI and XAML, which changes the application's codebase and runtime behavior. That rewrite can expose new performance characteristics vs. the old Win32 code. (windowscentral.com, pureinfotech.com)
  • However, “XAML = slow” is an oversimplification. Some slow paths are caused by async/architecture decisions (file enumeration on the UI thread, many small awaits, I/O on the UI thread) — problems that can exist in any framework if the I/O/CPU work is not offloaded properly. Microsoft and WinUI maintainers have active discussions about these performance tradeoffs. (github.com, techradar.com)
  • A discrete GPU by itself does not “fix” UI overhead that runs on the CPU or is blocked by async calls. On many machines (especially hybrid laptop GPUs and power‑savings profiles) the system may prefer integrated graphics for lightweight UI, so a gaming GPU doesn’t automatically accelerate those UI code paths. Vendor settings and Windows power rules determine which GPU is used. (amd.com, nvidia.com)
If you want the quick explanation in one line:
  • Modern UI frameworks (WinUI / XAML) give Microsoft more flexible, uniform visuals — and that rework can expose new bottlenecks (I/O + UI thread interactions, async patterns) that make simple operations feel slower than the older native Win32 code unless properly optimized. (windowscentral.com, github.com)
What Touch Reviews got right — and where the article stretches
  • Right: Microsoft has been moving parts of the OS to WinUI/XAML. The new File Explorer samples and the 23H2 work are explicit examples: Microsoft has rebuilt or reworked Explorer with the Windows App SDK / WinUI and XAML. That’s documented and widely reported. (windowscentral.com, pureinfotech.com)
  • Right: Many users do report that UI interactions feel less snappy in Windows 11 than they remember from Windows 10. There are many bug reports, forum threads and Feedback Hub items describing slow context menus, slow Explorer, and jank in certain scenarios. Microsoft is actively collecting more diagnostic data and iterating. (techradar.com, learn.microsoft.com)
  • Likely wrong / sloppy: the article’s reference to “XML islands” appears to be a mistaken name; the correct term is XAML Islands (XAML, not XML). That matters because XAML is a specific UI markup framework (Extensible Application Markup Language used by UWP/WinUI) with documented hosting techniques and known constraints; “XML islands” is not an OS UI technology. The Microsoft documentation is explicit about this. (learn.microsoft.com)
Why switching to XAML/WinUI can create new performance patterns
(Short technical primer — skip if you don’t want the implementation detail)
  • Architecture shift: The legacy File Explorer and many shell components were written with Win32 APIs that often used synchronous, tightly‑optimized code paths. WinUI/XAML introduces a different runtime model (retained UI, a composition system, and more asynchronous patterns). That’s not inherently slower, but it changes where work happens and how latency accumulates. (windowscentral.com, en.wikipedia.org)
  • Async + UI thread traps: In modern UWP/WinUI code, file enumeration, thumbnails, and metadata are frequently implemented with async methods. Each "await" resumed on the UI thread causes scheduling overhead; a build‑up of many small awaits or running I/O on the UI thread can add measurable delay before the UI completes rendering. WinUI/WinRT maintainers have raised this exact point in performance threads. (github.com)
  • Composition & features: XAML/WinUI exposes richer composition (animations, blurs, acrylic, Mica, etc.). These costs are distributed — some are GPU accelerated, others are CPU/driver‑bound (e.g., building bitmaps, measuring layout, text shaping). If the implementation isn't optimized for a particular hardware profile, the perceived result is “sluggishness.” (en.wikipedia.org, windowscentral.com)
  • Mixed codebase complexity: When a process hosts XAML content inside classic shell processes (or vice versa), there are interop layers and edge cases (e.g., theme propagation, window hosting) that can blow up unexpected latency unless carefully engineered. Microsoft documents several XAML Islands limitations and required workarounds. (learn.microsoft.com)
Why a gaming GPU often won’t “solve” the complaint
  • Two different bottlenecks: If the delay is caused by CPU work (file metadata enumeration, many small asynchronous callbacks) the GPU can’t help — the UI is waiting for data. Conversely, GPU acceleration helps when the bottleneck is raw rasterization/composition of pixels. Many of the slow interactions people notice (context menu latency, folder enumeration) are CPU/IO limited. (github.com)
  • Hybrid GPU behavior and power management: On laptops with both integrated and discrete GPUs, Windows and OEM drivers often prefer integrated GPU for power savings for low‑demand scenarios; discrete GPUs will be used for heavy GPU workloads or when the app is explicitly pinned to the dGPU. That means having a powerful graphics card in the machine doesn’t guarantee the OS will use it for every window or menu. You have to check Windows graphics preferences and vendor control panels. (amd.com, nvidia.com)
  • Real‑world evidence: Microsoft has begun collecting targeted logs from Insiders about “system sluggishness” and listed context‑menu/File Explorer slowness among the top concerns — a sign they see these as software/architectural issues to be fixed rather than simple GPU tuning. (techradar.com)
What the community and Microsoft engineers are saying (verified citations)
  • Microsoft docs: XAML Islands is an official feature and has specific runtime constraints and workarounds. That documentation explains hosting XAML in Win32/WPF and lists performance and functional limitations to be aware of. (learn.microsoft.com)
  • Reporting & fixes: Microsoft is rolling targeted diagnostic collection for “sluggish system behavior” in Insider builds to get more telemetry and root causes for the lag people report. That program and public statements indicate they are treating the problem as a multi‑factor software issue. (techradar.com)
  • WinUI performance discussion: WinUI's GitHub issue threads contain concrete developer observations — for example: many small awaits on the UI thread (file enumeration) can add ~10ms per await and accumulate into visible latency; advice given is to batch I/O off the UI thread or use ConfigureAwait(false). That’s a key technical explanation for why some operations feel slower after a modern rework. (github.com)
  • Reporting on the Explorer rewrite: multiple reputable outlets confirmed that Microsoft rewrote parts of File Explorer with WinUI/Windows App SDK and XAML as part of the 23H2-era modernization. That’s not rumor; it’s a documented engineering direction. (windowscentral.com, pureinfotech.com)
What I checked but could not independently verify
  • The Touch Reviews piece attributes the discovery to a specific YouTuber named “epcidiy.” I looked for the original video or primary code snippet from that channel and could not find a verifiable copy or public repository attributing the exact code lines claimed in the article. Until the original video or code is published, treat the attribution as uncorroborated reporting and not a primary technical source. If you can share a link to the epcidiy upload, I’ll verify the exact claim line‑by‑line. (I did fetch the Touch Reviews article to summarize its claims.)
Practical troubleshooting checklist (for users)
If you feel Windows 11 is snappier on Windows 10 and want to try to regain some responsiveness today, try these steps in roughly this order:
1) Rule out driver and OS updates
  • Update Windows 11 fully (Settings → Windows Update). Microsoft patches many of these issues in cumulative updates.
  • Update GPU drivers (NVIDIA/AMD/Intel) from vendor sites (or OEM if recommended). Hybrid GPU machines are sensitive to driver combos. (learn.microsoft.com, nvidia.com)
2) Turn off animations and transparency (quick win)
  • System → Accessibility → Visual effects → turn off animation effects, or Performance Options → Adjust for best performance. Many users see dramatic improvement. Community threads and forums show this repeatedly. (elevenforum.com, reddit.com)
3) Check File Explorer tweaks
  • If the modern menu is slow, you can temporarily revert to the classic context menu via registry tweaks or third‑party tools; Windows Central has a detailed guide with reversible steps. (Back up registry first.) (windowscentral.com)
4) Force the dGPU for apps where you want it
  • Settings → System → Display → Graphics → choose an app and set “High performance” (discrete GPU). Also check the vendor control panel (NVIDIA/AMD) to force/disallow dGPU for particular apps. This helps for GPU‑heavy tasks but won’t fix CPU/IO UI stalls. (answers.microsoft.com, nvidia.com)
5) Power plan and CPU core behavior (especially hybrid Intel/AMD CPU designs)
  • Use High performance / Performance power profile for workstations where latency matters. On hybrid CPUs (performance & efficiency cores), experiment with min/max processor state and power profiles. Some users report improved snappiness after forcing higher minimum CPU states. (learn.microsoft.com)
6) Disable problematic shell extensions
  • Third‑party context‑menu handlers (e.g., old cloud storage, legacy shell integrations) can cause high latency when the menu builds. Use ShellExView or similar tools to selectively disable non‑Microsoft shell extensions and test. Many community threads point to shell extensions as common culprits.
7) Use Feedback Hub / provide the logs (Insiders)
  • If you’re on the Insider channel, use the new diagnostic collection for sluggish behavior so Microsoft receives the traces. For general users, collect repro steps and submit via Feedback Hub. Microsoft has explicitly asked for more structured slow/lag reports. (techradar.com)
8) If all else fails: fall back to a stable experience
  • If you rely on snappy Explorer for productivity and nothing helps, consider: a clean reinstall with a different image, downgrading to Windows 10 (if that’s feasible and supported), or using a lightweight third‑party file manager (Everything, XYplorer, etc.) as a practical band‑aid while Microsoft optimizes the modern shell. Many power users take this route temporarily.
How serious is this for businesses and professionals?
  • It depends on the workload. For UI‑heavy, high‑frequency productivity tasks where every click counts (dev, sysadmin, content production), cumulative UI latency adds up. Microsoft and enterprise IT pros track these regressions carefully. The 23H2/modernization effort is deliberate but Microsoft also receives enterprise feedback and frequently backports performance fixes when necessary. In other words: the issue is real where it matters to productivity, and Microsoft has acknowledged and is working on targeted telemetry and fixes. (techradar.com, windowscentral.com)
Final, practical note about the Touch Reviews article attribution
  • The Touch Reviews article is a useful signal that the conversation is active and that users are seeing regressions. But the article conflates terms and attributes a narrow “silver‑bullet” cause to a single reviewer’s code inspection. The underlying technical reality is broader and more incremental: WinUI/XAML introduces new patterns and new bottlenecks are emerging, but the fix is not as simple as “turn off XAML” — it’s an engineering process that Microsoft and the WinUI community are actively working through.
If you want, next I can:
  • Look up and watch the epcidiy video (if you can share the link) and verify the exact code excerpt they reference line‑by‑line. I could then annotate which bit of the Windows code or XAML/WinUI behavior they are inspecting and whether it alone explains the observed lag.
  • Build a tailored troubleshooting script/checklist for your machine (I’ll need your CPU/GPU model, whether it’s a laptop with hybrid GPU, and whether you’re on Insider builds).
  • Produce a short “how to roll back to classic context menus / accelerate File Explorer” guide with exact registry commands and screenshots.
Which of the above would be most helpful? If you’ve got that epcidiy link, paste it and I’ll verify the primary source and quote the exact code lines.

Source: touchreviews.net He was so fed up with how slow Windows 11 was compared to Windows 10 that he looked into the code and found a detail that explained everything - Touch Reviews