@Popdupe
Go to Perplexity.ai (‘https://www.perplexity.ai’) and ask:
What might you know about Chromium “compositing layers” textures and rendering tasks to GPU, that lead to higher RAM usage by Chromium tabs and the Windows Operating System’s Desktop Window Manager - showing in the Brave Browser Task Manager and Windows OS Task Manager?
Result:
Chromium’s compositing system builds GPU-backed layers, tiles them into textures, and hands those textures to the GPU and then to Windows’ Desktop Window Manager (DWM); this pipeline is what inflates both per‑tab memory usage and DWM usage in task managers.
How layers become GPU textures
Chromium promotes certain render layers (e.g., with transforms, opacity, videos, animated elements) into compositing layers that are backed by their own surfaces instead of a single big page bitmap.
These surfaces are divided into tiles, rasterized, and uploaded as textures by the compositor/GPU threads, so a single tab can easily maintain dozens or hundreds of textures in memory for smooth scrolling and animation.developer.
To manage this, Chromium’s GPU memory manager assigns each tab (layer tree) a memory budget and prioritizes tiles near the viewport or on animating layers, keeping them resident while evicting others.chromium.
Even when a tile is evicted from GPU memory, there may still be shared-memory backing in system RAM, so memory appears “used” in both the renderer process and the GPU process.
Why Brave’s tab RAM usage goes up
Brave uses Chromium’s RenderingNG, so each tab’s renderer process allocates shared bitmaps or GPU resources for its layer tiles, plus bookkeeping data structures for the compositor.
Brave’s task manager then attributes a slice of that shared memory and tile/cache usage to each tab, so tabs with long, complex, or animated pages show noticeably higher RAM even if you only see “a web page.”
Because tiles are cached to avoid re‑rasterizing when you scroll back or animate again, memory usage tends to grow as you interact with a page, then only gradually shrink as the cache evicts unused tiles.
GPU paths that use “one‑copy” or “GPU” tile modes lean more on GPU memory, but they still rely on staging/shared memory in the renderer or GPU process, which shows up as additional RAM in task managers.
Why DWM’s memory usage goes up
On Windows, Chromium’s compositor ultimately submits swap chains or composition surfaces to DWM (dwm.exe), which is the system compositor that renders the desktop.
Each visible browser window (and sometimes each tab in special cases like separate windows) results in one or more surfaces that DWM must keep in GPU memory (and some system RAM) to composite the final screen image with effects like transparency and scaling.
When Chromium uses many GPU-backed layers and textures, the resulting backbuffers and intermediate surfaces have to be handled by DWM, so DWM’s GPU and memory usage grows with the number and size of windows, their resolution, and the complexity of their contents.
From your perspective, that means the same underlying textures and surfaces are “counted” in three places: the tab/renderer, the shared GPU process, and DWM, which makes overall memory usage look larger than a single in‑process software renderer would.chromium.
Why this is a deliberate trade‑off
All of this extra memory exists to make rendering smooth: cached tiles and textures let the compositor redraw frames while the main thread runs JavaScript, and let DWM animate windows and the desktop without re‑painting everything each frame.
The Chromium team tunes budgets and eviction heuristics (distance from viewport, animation state, recency) to keep memory within bounds, but the design fundamentally trades higher RAM/VRAM usage for responsiveness and lower CPU cost on modern GPUs.
Also asked:
Was OpenGL replaced on Windows OS machines?
Result:
No. On Windows, OpenGL has not been “replaced” in the same way Metal has effectively replaced OpenGL on Apple platforms.
- Windows still supports OpenGL via the long‑standing Installable Client Driver (ICD) model, where GPU vendors ship OpenGL drivers that apps can use directly. Direct3D (part of DirectX) is Microsoft’s preferred and most actively advanced 3D API, especially for games, but it exists alongside OpenGL, not as a hard replacement.learn.
- If a proper vendor OpenGL driver is installed, OpenGL calls are hardware‑accelerated; if not, Windows can fall back to an old software OpenGL 1.1 implementation, which is slow but still present.
- Modern engines targeting Windows almost always use Direct3D (or a cross‑platform abstraction over Direct3D/Vulkan/Metal/etc.), so in practice OpenGL’s importance has declined, but it remains available and functional on Windows rather than being deprecated by the OS.
Also asked a modified version of my first:
What might you know about Chromium “compositing layers” textures and rendering tasks to GPU, that lead to lagging, stuttering, and higher RAM usage by Chromium tabs and the Windows Operating System’s Desktop Window Manager - showing in the Brave Browser Task Manager and Windows OS Task Manager?
Result:
Chromium-based browsers like Brave use GPU-accelerated compositing to offload rendering tasks from the CPU to the GPU, which can sometimes cause lagging, stuttering, and elevated RAM usage visible in Brave’s Task Manager and Windows Task Manager (including DWM spikes).
Compositing Layers Basics
Compositing layers break web page elements (like RenderLayers) into separate GraphicsLayers, each potentially backed by a texture for efficient GPU blending and transforms (e.g., scrolls, animations). This promotes parallelism between CPU and GPU but promotes layer “explosion” if many overlapping elements qualify, leading to excessive textures.
Textures and GPU Tasks
Textures store rasterized content (from software bitmaps or direct GL/WebGL) in VRAM; uploads from CPU to GPU via async workers can bottleneck on memory bandwidth, especially with tiling (splitting layers into tiles for partial rasterization). Infinite or inefficient uploads during scrolls exacerbate GPU/CPU contention, OOM errors, or stuttering if VRAM fills.
Performance Issues
- High tab counts amplify processes (one per renderer/plugin/extension), inflating RAM as each manages its layer tree and textures.
- DWM (Desktop Window Manager) spikes occur when compositing browser UI with content layers, copying large viewports frame-by-frame.
- Stuttering ties to rasterization delays, texture copies, or driver issues (e.g., D3D11 vs. OpenGL), worsened by HDR or background tabs.
Mitigation Steps
- Disable hardware acceleration (
brave://settings/system) to force software rendering, reducing GPU/DWM load but increasing CPU use.
- Tweak flags like
brave://flags search for override-software-rendering-list or limit layers.
- Close unused tabs/profiles; monitor Brave Task Manager for high GPU tasks in specific renderers.
- Reference: brave
Adding . . .
How VRAM / resource competition plays into it:
Several layers are competing over GPU policy and scheduling:
- Browser layer (Brave/Chromium): decides which GPU features to use (Skia, ANGLE backend, Vulkan/D3D, rasterization paths) and how aggressively to utilize the GPU.
- Driver layer (Nvidia/AMD/Intel): applies profiles, frame caps, power management, and prioritization rules that may treat Brave as a game and apply VRAM and frame‑rate policies tuned for full‑screen 3D workloads.
github
- OS layer (Windows / Game Mode / Graphics Settings): decides which GPU “owns” Brave and whether it should be throttled or prioritized compared with background tasks.
reddit
When any of those three layers makes a bad assumption (for example, “this app is a 3D game, cap its framerate and run it on the dGPU”) you can see:
- UI lag when hardware acceleration is on.
- Hardware acceleration disabling itself partway through (e.g., after visiting YouTube) and dumping load back to the CPU. github
- Very different behavior between Brave and Chrome on the same machine, even though both are Chromium‑based.
github
