Improve rendering performance on Windows - #728
Merged
Merged
Conversation
mehmetozguldev
self-requested a review
July 16, 2026 21:28
Make the main window opaque on Windows so WebView2 leaves the per-pixel alpha composition path. The window is already painted opaque there, so nothing changes visually while compositing gets the GPU fast paths back. Enable GPU rasterization flags for the webview and promote the menubar and combobox popups to their own compositor layer with a platform-windows root class, keeping their open/close transitions identical but composited on the GPU instead of re-rasterized on the main thread.
Grant the window capabilities the custom title bar needs to minimize and toggle-maximize on Windows, and give the menubar popup positioners explicit z-index values so menus and submenus stack above the workbench chrome.
joordih
force-pushed
the
fix/windows-performance
branch
from
July 16, 2026 21:42
3b42247 to
66f5f88
Compare
Member
|
I appreciate the PR! I'll test the changes on Windows now and hopefully merge after that. Code looks clean |
Keep the opaque Windows window and compositor hints without shipping WebView2 diagnostic GPU flags that bypass hardware safeguards. Make platform classes exclusive and grant the remaining window menu capabilities with regression coverage for the runtime configuration.
Member
|
Thanks again. I pushed a follow-up that keeps the opaque Windows window while removing production GPU override flags, makes platform classes exclusive, completes the window menu capabilities, and adds regression coverage. |
mehmetozguldev
approved these changes
Jul 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Windows rendering has been noticeably behind macOS, especially menu and popup transitions. This PR closes most of that gap without changing a single pixel or animation: every change is Windows-gated, macOS and Linux are untouched.
What changed
Opaque main window on Windows (
src-tauri/tauri.windows.conf.json, new)The base config sets
transparent: truefor every platform, but only macOS uses it (the glass chrome is gated onplatform-macos, andconfigure_app_windowalready paints the Windows background opaque). WebView2 pays a real cost for transparent windows: the whole surface goes through per-pixel alpha composition and loses GPU fast paths. Windows now gets its own platform config withtransparent: false, mirroring howtauri.macos.conf.jsonalready works. Since the window was always painted opaque there, nothing changes visually.GPU rasterization flags for WebView2 (same file)
additionalBrowserArgsadds--enable-gpu-rasterization --enable-zero-copy --ignore-gpu-blocklist, with Tauri's default Windows args re-included since this field replaces them.Compositor hints for popup transitions (
use-platform-setup.ts,window-transparency.css)The root element now gets a
platform-windowsclass (Windows previously sharedplatform-otherwith Linux, so it couldn't be targeted separately). Menubar and combobox popups getwill-change: opacity, transform, filteron Windows: the exact same open/close transitions, but composited on the GPU instead of re-rasterized on the main thread every frame.Window controls and menu stacking (
capabilities/main.json,menubar.tsx)The custom title bar needs
core:window:allow-minimizeandcore:window:allow-toggle-maximizeto work on Windows. Menubar popup positioners get explicit z-index values so menus and submenus stack above the workbench chrome.Notes
tsc --noEmitclean.