Does Hardware Acceleration Help a Tiny Overlay?

The default assumption is that hardware acceleration is faster, and therefore that any application should enable it. For a large, frequently-updating window — a video player, a game, a 60 FPS animation — that assumption is correct. For a small, mostly-static overlay like a clipboard shelf, the assumption is often wrong. The GPU process that hardware acceleration requires costs more idle RAM than it saves in render time, and a shelf that repaints only when the user opens it does not need the GPU at all. This guide explains when hardware acceleration helps a tiny overlay, when it hurts, and how to decide based on the overlay's actual repaint rate.

For neighbouring topics, see high refresh pointers and hover dwell times and measuring clipboard app idle cost yourself.

What hardware acceleration actually is

On Windows, "hardware acceleration" in an Electron or Chromium context means that the GPU process is responsible for compositing the window's layers and pushing pixels to the screen. Without hardware acceleration, the same compositing is done in software, on the CPU, by the Skia rasteriser.

The GPU process is a separate process from the renderer process. It has its own memory, its own command buffer, and its own cost. On a typical Electron app, the GPU process accounts for 30–60 MB of additional RAM at idle, on top of the renderer's 80–120 MB. This is true even if the window is not actively rendering — the GPU process stays alive to be ready for the next frame.

For a tiny overlay — say, 80 pixels wide by 600 pixels tall, mostly transparent, with a handful of cards — the rendering work is trivial. A software rasteriser can composite the entire frame in under a millisecond on any modern CPU. The GPU process offers no meaningful speedup, because there is nothing to speed up.

When the GPU process earns its keep

Hardware acceleration is worth its cost when the window does any of the following:

• Renders video. A video tag playing at 60 FPS needs the GPU to decode and composite; software video decode is roughly 5× the CPU cost.
• Renders continuous animation. A spring-physics animation that repaints every frame benefits from GPU compositing, especially if it involves blur or other expensive filters.
• Renders large bitmaps. A 4K image displayed in the window is a lot of pixels; the GPU can scale and composite it faster than the CPU.
• Uses CSS filters or backdrop-blur. A frosted-glass overlay with backdrop-filter: blur(20px) is dramatically cheaper on the GPU.

A clipboard shelf does almost none of these. Its normal render path is: show the shelf, render the history cards, wait for user input. The cards themselves are small text and thumbnails. There is no continuous animation; the open animation is a single 200 ms fade or spring that runs once and stops.

When software compositing wins

For a tiny, mostly-static overlay, software compositing has three advantages:

• Lower idle RAM. Without the GPU process, the app's idle RAM is roughly 30–60 MB lower. For a clipboard manager that runs all day, that is a meaningful saving.
• Lower idle CPU. The GPU process, even when idle, polls for new commands at a low rate. Software compositing has no such polling; the renderer only runs when the window actually needs to repaint.
• More predictable behaviour on integrated GPUs. On older integrated GPUs, transparent windows with hardware acceleration can stutter or tear, because the integrated GPU's memory bandwidth is shared with the CPU. Software compositing avoids this entirely. See integrated GPUs and transparent windows for the full discussion.

The cost of software compositing is that the rare animation (the open fade, the spring) is slightly less smooth on the CPU. For a 200 ms fade, the difference is barely perceptible. For a continuous animation, the difference is large.

The decision matrix

The right answer depends on what the overlay actually does:

The pattern: hardware acceleration earns its keep when there is continuous, expensive rendering work. For everything else, software compositing is lighter and equally fast.

How to disable hardware acceleration in Electron

Electron exposes a disableHardwareAcceleration flag in the app's main process. The flag must be set before the app's ready event; it cannot be toggled at runtime. The flag tells Chromium not to spawn the GPU process at all, which saves the 30–60 MB of idle RAM and the small idle CPU cost.

const { app } = require('electron');
app.disableHardwareAcceleration();

The cost: any CSS that relies on the GPU (3D transforms, backdrop-filter) will not work, and large video or image content will be rasterised on the CPU. For a clipboard shelf that does not use any of these, the cost is zero.

For end users of an Electron app that does not expose this flag, the equivalent is to launch the app with the --disable-gpu command-line flag. This works on any Chromium-based app, including Electron. The flag is not persisted; it must be added to the shortcut or the launch script.

Measuring the difference

The honest way to verify the trade-off is to measure it:

1. Launch the overlay with hardware acceleration on. Note the idle RAM and idle CPU in Task Manager after 60 seconds of no interaction.
2. Quit the overlay. Relaunch with --disable-gpu (or with disableHardwareAcceleration if you control the source).
3. Note the idle RAM and idle CPU again, after the same 60-second settle.

The difference is the GPU process tax. For a tiny overlay, it is typically 30–60 MB of RAM and a small but non-zero CPU delta. For a video-heavy app, the delta is smaller (the GPU is doing useful work) and the trade flips.

For the methodology, see measuring clipboard app idle cost yourself.

The dual-GPU laptop wrinkle

Laptops with both an integrated GPU and a dedicated GPU add a complication. Chromium's GPU process picks one GPU at startup based on the OS's preferred adapter, which is usually the integrated GPU for power efficiency. When the laptop later switches to the dedicated GPU under load, the GPU process may not migrate, leading to compositor stalls or transparent-window flicker that disappears after a restart. This is well-documented on NVIDIA Optimus and AMD Switchable Graphics configurations.

For a tiny overlay, the simplest workaround is to disable hardware acceleration entirely — software compositing is immune to the GPU-switch problem because it does not use either GPU. Users who need the dedicated GPU for another app and also need the overlay to be stable should launch the overlay with --disable-gpu and leave the dedicated GPU for the workload that actually benefits from it. The overlay loses nothing in the trade.

Honest positioning

Edge-Drop, the Windows hover-activated clipboard shelf, is Electron-based and currently runs with hardware acceleration enabled by default. The shelf's render path is mostly static — cards are rendered once and only re-rendered on user interaction — so the GPU process is not doing much useful work. The honest assessment is that disabling hardware acceleration on the shelf would reduce idle RAM by roughly 30–50 MB and would have minimal visual cost; this is a tuning option the shelf could expose but does not as of mid-2026. The shelf's overall idle RAM (typically 130–160 MB) is in line with other Electron utilities and is higher than Ditto or Win+V; users for whom 50 MB matters should use those lighter tools. For the full comparison, see best clipboard manager for low-RAM PCs and edge-drop vs ecopaste: Electron drag hub vs Tauri RAM.

What to check

If your overlay is using more idle RAM than expected, work through these:

1. Is hardware acceleration enabled? (Check for a GPU process in Task Manager's Details tab.)
2. What is the GPU process's idle RAM? (Typically 30–60 MB.)
3. Does the overlay actually need the GPU? (Look at the render path: continuous animation, video, or backdrop-blur.)
4. If not, disable hardware acceleration and re-measure.
5. If the overlay does need the GPU for a specific animation, consider disabling it only when the overlay is collapsed, and re-enabling on open. (This is more complex but preserves the animation while saving idle RAM.)

The right answer for most clipboard shelves is software compositing. The right answer for a video player is hardware acceleration. The wrong answer is to enable hardware acceleration by default on the assumption that it is always faster.

Related reading

• Measuring Clipboard App Idle Cost Yourself
• Sleep/Wake False Copy Events
• Clipboard Tools on Multi-Monitor Windows Setups
• Win+V Not Working on Windows 11: 9 Fixes

Sources

• Electron — disableHardwareAcceleration — official Electron API reference for disabling the GPU process
• Chromium — GPU architecture — Chromium project documentation explaining the GPU process, its role, and its cost
• Microsoft Learn — DirectComposition — Windows reference for the composition API that powers both hardware-accelerated and software-composited windows
• Microsoft Learn — Transparent windows — Win32 reference for layered windows and the composition cost of transparency
• Skia — Raster backend — Skia project documentation for the software rasteriser used when hardware acceleration is disabled

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support