Disable hardware acceleration in Chrome: when the screen starts tearing

The instruction to disable hardware acceleration in Chrome shows up in support articles for video conferencing tools, screen recorders, university help desks, and note-taking apps. It is the shortest sentence a support team can write that fixes a whole family of graphics complaints, and it is handed out with no mention of what it costs. For a torn, flickering, half-black window it is the right call. For a browser that feels slow, it is the wrong lever pulled with confidence.

The setting itself takes ten seconds. The decision around it is the part worth getting right, because leaving acceleration off permanently means paying CPU time and battery for every video call and every scroll, for the rest of the machine's life, in exchange for a problem that may have been fixed by a driver update months ago.

The symptoms that justify it

Turning acceleration off removes the graphics driver from the drawing path. That only helps when the defect is in that path, and those defects look distinctive.

Tearing. Horizontal bands where the top and bottom of the window belong to different frames, most visible while scrolling or during a video.

Black or blank rectangles. Parts of the page drawing as solid blocks, often the video area of a call or a section of a page that has just scrolled into view.

Flicker after a display change. A window that renders correctly until the Mac wakes from sleep, or until an external display is connected or disconnected, then flickers or shows stale content until the window is resized.

Garbled or ghosted text and images. Characters with coloured fringes, duplicated strips of a previous frame, or images drawn with visible corruption that disappears on reload.

A GPU process that keeps crashing. Windows briefly going blank in every tab at once, repeatedly, is the GPU process restarting.

One check comes before any of this. If the tearing or flicker also appears outside the browser, in a video player, a design tool, or the desktop itself, the problem is not Chrome's to fix and disabling acceleration in one application only hides a fraction of it. Watching the same content in a second application for a minute separates a browser-level defect from a system-level one, and it is a faster test than any setting change. The same logic applies to an external display: a defect that appears only on one screen, or only at one refresh rate, is pointing at the cable, the adapter, or the display mode rather than at the browser's drawing path.

Symptoms that do not belong on this list are worth naming too, because they consume the most attempts. High memory use is a renderer and tab-count question, not an acceleration question. A single site being slow is usually that site's code. Chrome starting slowly, extensions misbehaving, and pages failing to load have nothing to do with the graphics path, and turning acceleration off will make the first of those worse rather than better.

Turning it off, exactly

The control is in Chrome's settings, under the System section, as a checkbox labelled "Use graphics acceleration when available". Unticking it and relaunching the browser is the whole procedure, and the relaunch is not optional: the setting is read when Chrome starts, which is why the settings page puts a relaunch button next to it.

Two things are worth doing around that click. First, note what the state was before, so a revert is possible without guessing. Second, confirm the change actually took effect by opening chrome://gpu after the relaunch and reading the feature list, which should now report software paths where it previously reported hardware ones. A setting that does not appear to change anything on that page usually means an enterprise policy is deciding it, since Chrome ships a policy that sets this behaviour centrally on managed machines.

The relaunch itself has one side effect worth knowing in advance. Chrome warns that an Incognito window will not reopen after a relaunch, because private sessions are deliberately not restored. Anything in progress in such a window, including a form that has not been submitted and a login that has not been completed, is gone once the browser restarts. Ordinary windows and tabs come back. Downloads in flight do not, so a large file arriving is a reason to wait ten minutes before clicking relaunch rather than a reason to skip the step.

The relaunch requirement is not a user interface habit, it is how the setting is defined. The same control exists as a managed policy, and its definition in Chromium's policy templates carries the caption "Use graphics acceleration when available", a default of enabled, and dynamic_refresh: false, which is the flag that marks a policy as one the browser cannot apply to a running instance. A setting declared that way can only take effect at startup, which is why a page that still looks wrong before the relaunch proves nothing at all.

Setting the policy to Enabled or leaving it unset turns on graphics acceleration, if available. Setting the policy to Disabled turns off graphics acceleration. Source: chromium source

On a managed Mac, a greyed-out checkbox is not a bug and not worth fighting. The policy page in the browser lists what is being applied, and the change has to come from whoever manages the machine.

Narrower switches than the global one

The checkbox is all or nothing, and most of the defects above come from one part of the graphics path rather than all of it. Chromium exposes narrower controls as command line switches, which matters because turning off only the broken part keeps the rest of the acceleration people actually benefit from.

--disable-accelerated-video-decode takes video decoding off the dedicated hardware block while leaving page composition accelerated. This is the one to reach for when the artifacts only ever appear inside video.

--disable-gpu-compositing stops layers being combined on the GPU while leaving other GPU work in place. This addresses tearing and stale-frame problems without giving up everything.

--disable-gpu is the blunt instrument, closest in effect to unticking the checkbox.

--disable-software-rasterizer does the opposite of what its name suggests to most readers: it removes the software fallback rather than the hardware path, so a machine that cannot use its GPU ends up with no 3D path at all. It exists for testing and is not a fix for anything. The comment beside it in Chromium's switch definitions reads simply "Disables the use of a 3D software rasterizer", and the comment beside --disable-gpu in the same file spells out the consequence of combining the two: with hardware acceleration disabled and no software renderer in place, the GPU process does not launch.

Switches apply to a launch rather than to a profile, which cuts both ways. A test is clean and ends when the browser is quit, and a fix does not survive the next ordinary launch from the Dock. That makes them right for isolating a cause and wrong as a permanent configuration.

Compare the scope before choosing

Lever	What it stops	Survives a normal relaunch	Good for
Settings checkbox	All GPU rendering	Yes	A defect that follows every kind of drawing
Disable accelerated video decode	Hardware video decoding only	No, per launch	Artifacts confined to video
Disable GPU compositing	Layer composition on the GPU	No, per launch	Tearing and stale frames
Disable GPU	Effectively all GPU work	No, per launch	Confirming the GPU path is the cause
Update the driver or macOS	Nothing, it changes the driver	Yes	The actual fix in most cases

The last row is the one that gets skipped. Chrome carries an internal list of operating system, GPU, and driver combinations it refuses to accelerate, and that list is maintained because these defects are usually specific driver versions rather than hardware. A system update that changes the driver fixes the symptom and keeps the performance, which no amount of setting-flipping can do.

What the change costs

With acceleration off, the same work still happens. It happens on general-purpose CPU cores instead of hardware built for it.

Video decoding is where this is most visible. A long call or a playback session that barely registered before will push CPU use up, spin the fans, and shorten battery life measurably, because a dedicated decode block is far more power-efficient at that job than software. On a laptop away from power, this is the difference people notice within an hour.

Page composition moves to a software compositor. Output stays correct, and heavy pages with sticky elements, large scrolling areas, or CSS animation start to stutter under load in a way they did not before.

Three-dimensional content falls back to a software implementation of the graphics API. Maps, dashboards, and design tools keep working and run slowly, and some of them will notice and warn that acceleration is unavailable.

The size of that cost is not fixed. It scales with the number of pixels being pushed, so a laptop driving a single built-in display absorbs the change far better than the same laptop driving two external monitors, where the software compositor has several times the area to redraw on every frame. Playback resolution matters in the same way, and a call at full resolution with a dozen participant thumbnails is close to the worst case. This is why one person reports barely noticing the change while another finds the browser unusable, on the same model of machine and the same setting.

There is a second-order cost as well. Once drawing shares the CPU with page code, the browser becomes more sensitive to whatever else the machine is doing, so an unrelated background task now shows up as jerky scrolling. That is worth knowing before concluding that the fix caused a new problem.

Test it so the result means something

Graphics defects are intermittent, which makes them easy to declare fixed. Three habits prevent that.

Change one thing. A relaunch with acceleration off, and nothing else touched in the same sitting, is a test. A relaunch with acceleration off, two flags reset, and an extension removed answers nothing.

Give it the time the defect needs. Something that appeared twice a day is not fixed after twenty minutes. Note the trigger while it is fresh, including which app and which action produced it, because the trigger is what makes the next check quick.

Revisit the decision. Leaving acceleration off is a standing cost, so the setting deserves rechecking after a macOS update or a few Chrome releases, both of which can change what Chrome allows on that hardware. Turning it back on and watching for the symptom is a five-minute test.

Isolating which app the defect follows is easier when the apps are not all in one window. When each tool has its own window and its own session, a defect that only ever appears in the video call and never in the document editor is obvious immediately, and the list of apps that run in their own space covers most of the tools involved in these reports.

What to change first

Open chrome://gpu and check whether the affected feature is already running in software, because if it is, the graphics path is not the cause and the checkbox will change nothing. If it is accelerated, try the narrow switch that matches the symptom before the global setting, then look for a macOS or driver update that makes the workaround unnecessary. A setup like SpaceDeck that keeps each app in its own window makes the test faster, because the defect either follows one app or it does not.