macOS Apple M2: Severe Brave lag with graphics acceleration enabled, fixed by disabling graphics acceleration

[rhycecomley]

Description

Brave becomes severely slow/janky on macOS when “Use graphics acceleration when available” is enabled. Disabling graphics acceleration and relaunching Brave massively improves performance.

The issue appears to affect Brave’s Chromium/GPU/compositor path rather than general internet speed, because the same browser/profile becomes much more responsive when graphics acceleration is disabled.

The strongest signal is that with acceleration enabled, brave://gpu shows Brave using ANGLE Metal + Skia Graphite/Dawn/Metal on Apple M2, but performance is much worse than when acceleration is disabled and Brave falls back to software rendering/compositing.

This also appears to line up with behaviour in other Chromium/WebView-style apps feeling slow, suggesting a possible Chromium/macOS graphics/compositor issue.

Steps to reproduce

1. Open Brave on macOS.
2. Go to brave://settings/system.
3. Enable “Use graphics acceleration when available”.
4. Relaunch Brave.
5. Use Brave normally: scroll pages, type into text fields, switch tabs, and use web apps.
6. Observe severe lag/jank/slowness.
7. Go back to brave://settings/system.
8. Disable “Use graphics acceleration when available”.
9. Relaunch Brave.
10. Repeat the same browsing behaviour.
11. Observe that Brave becomes massively more responsive.

Actual result

With graphics acceleration enabled, Brave becomes very slow and janky. UI responsiveness, scrolling, typing, and general page interaction feel delayed.

With graphics acceleration disabled, Brave performance improves massively.

I have attached two brave://gpu exports:

1. Acceleration ON / slow state
2. Acceleration OFF / fast workaround state

In the acceleration ON report, Brave is using the Apple M2 GPU path via ANGLE Metal and Skia Graphite/Dawn/Metal:

• Canvas: Hardware accelerated
• Compositing: Hardware accelerated
• OpenGL: Enabled
• Rasterization: Hardware accelerated
• Skia Graphite: Enabled
• Video Decode/Encode: Hardware accelerated
• WebGL/WebGPU: Hardware accelerated
• Skia Backend: GraphiteDawnMetal
• GL_RENDERER: ANGLE (Apple, ANGLE Metal Renderer: Apple M2, Version 26.4.1)

In the acceleration OFF report, Brave falls back to software rendering/compositing:

• Canvas: Software only. Hardware acceleration disabled
• Compositing: Software only. Hardware acceleration disabled
• OpenGL: Disabled
• Rasterization: Software only. Hardware acceleration disabled
• Video Decode/Encode: Software only. Hardware acceleration disabled
• WebGL/WebGPU: Disabled

Despite hardware acceleration normally being expected to improve performance, the software-rendering workaround is massively faster and more responsive on this system.

Expected result

Brave should remain smooth and responsive with graphics acceleration enabled on macOS/Apple Silicon.

Disabling graphics acceleration should not be required as a workaround for normal browser responsiveness.

Reproduces how often

Consistently while graphics acceleration is enabled. Performance improves consistently after disabling graphics acceleration and relaunching Brave.

Brave version / system information

• Brave version: [paste exact Brave version from brave://version]
• Chromium version shown in brave://gpu: Chrome/147.0.7727.137
• Operating system: macOS 26.4.1
• Device: MacBook Pro, Apple M2
• Machine model: Mac14,7

Additional information

Environment from brave://gpu:

• Operating system: Mac OS X 26.4.1
• Chromium version shown: Chrome/147.0.7727.137
• Device/GPU: Apple M2
• Machine model: Mac14,7
• Graphics path with acceleration enabled: ANGLE Metal Renderer / Apple M2
• Skia backend with acceleration enabled: GraphiteDawnMetal
• Display: internal display
• Display bounds: 1680x1050
• Scale factor: 2
• Refresh rate: 60 Hz
• Colour: P3, 10-bit

Driver bug workarounds shown with acceleration enabled:

• disable_2d_canvas_auto_flush
• enable_webgl_timer_query_extensions
• disabled_extension_GL_KHR_blend_equation_advanced
• disabled_extension_GL_KHR_blend_equation_advanced_coherent

Problems detected with acceleration enabled include:

• glFlush error on Mac
• disable_2d_canvas_auto_flush workaround applied
• Disable KHR_blend_equation_advanced until cc shaders are updated
• WebGPU-on-Vulkan-via-GL interop disabled

This appears to be a macOS/Apple Silicon/ANGLE Metal/Skia Graphite graphics acceleration performance issue, because disabling graphics acceleration is a full workaround.

As im new to the community its not letting upload the reports from brave://gpu

[rhycecomley]

Additional note: I have not yet tested this in a clean temporary Brave profile. I can do that if it would help isolate whether this is profile/extension-specific or a broader macOS/Apple Silicon graphics acceleration issue

[289wk]

@rhycecomley

May help you to monitor the Brave Browser Task Manager window that displays column titles:

→ Task | Memory footprint | CPU | Process ID | Image cache | Script cache | GPU memory | JavaScript memory

When you add columns in the Brave Browser Task Manager window, they may not appear in the same arrayed order as in my screenshot example ← not a problem.

Display all rows, all tasks, for your investigation:

---

Create a new user Profile for Testing:

Create and use AN ADDITIONAL Brave Browser user Profile (Menu --> More tools --> Add profile) - only ← meaning: Do not have any other Brave Browser user Profile tabs/windows open.

When creating this new Brave Browser user Profile for test purposes

• Do not import anything.
• Do not add any extensions.
• Do not allow/enable any Brave Browser “bells and whistles” such as Brave Rewards, Brave Talk, etc.

IF this test Brave Browser user Profile does not present your problem, then possibly, the profile that you have been using, has a problem . . . and that might be caused by one or more extensions, or too many tabs ← complex/conundrum.

Extensions Tests:

• test by disabling all extensions
• test by enabling each extension individually
• test by uninstalling all extensions
• test by installing each extension individually
• test combinations of extensions
• test order of installation of extensions

[rhycecomley]

Thanks — I retested using a temporary Brave profile with extensions forcibly disabled:

open -na "Brave Browser" --args --user-data-dir=/tmp/brave-clean-no-extensions --disable-extensions

Test conditions:

• temporary user data directory
• no imports
• no sign-in
• extensions forcibly disabled
• graphics acceleration enabled
• MotionMark 1.3.1 and WebGL Aquarium used as rendering/GPU-heavy test pages
• Brave Browser Task Manager set to “All tasks”

In this run, the Task Manager no longer shows the Claude extension or any extension service worker, so this removes the extension variable from the test.

Result: the issue still appears to reproduce in this temporary no-extension profile. The pages remain visibly jittery/less smooth than expected with graphics acceleration enabled.

I captured Brave Browser Task Manager while the issue was visible. One screenshot shows:

• GPU Process: 104.7% CPU, 108 MB GPU memory, 435 MB memory footprint
• WebGL Aquarium tab: 77.2% CPU, 27.3 MB GPU memory, 50.6 MB memory footprint
• Browser: 0.3% CPU, 45.0 MB GPU memory, 121 MB memory footprint
• MotionMark tab: 0.0% CPU, 7.5 MB GPU memory, 113 MB memory footprint

Another screenshot during MotionMark activity shows:

• MotionMark tab: 104.9% CPU, 30.0 MB GPU memory, 212 MB memory footprint
• GPU Process: 19.1% CPU, 147 MB GPU memory, 417 MB memory footprint

So the issue does not appear to be caused by my normal profile or extensions. It still happens in a temporary no-extension profile, and disabling graphics acceleration remains the workaround that makes Brave feel significantly smoother overall.

[289wk]

@rhycecomley

Test > In your Global Shields Settings, Disable ‘Block fingerprinting’: and elsewhere in settings: clear cache, cookies, and history for all time… then restart the browser and compare the Graphics Acceleration ON/OFF results - when visiting a few webpages - and not visiting the benchmark/test sites.

Test > another Chromium browser

---

Why, for test purposes, Disable Global 'Block fingerprinting` … ? Because I have seen in the Developer Tools > Network window, a variety of endless looping when there is a failure to achieve stable activity/agreements between website and browser - particularly when Graphics/Hardware Acceleration and WebGL are involved. So, I asked ChatGPT:

Can you explain the relationship between Brave Browser setting “Block fingerprinting” and:

• device memory
• font
• hardware concurrency
• hardware acceleration / graphics acceleration
• keyboard
• language
• media devices
• screen
• user agent
• webgl

I am not certain now, but some time ago, among the Brave Browser settings … in order to allow WebGL (and thus, be able to sign on to some financial websites = banks, for example), Hardware Acceleration had to be turned ON.

But lately, Brave developers have expanded the Brave Site-Specific Shields > Block fingerprinting setting to display a list of “anti-fingerprinting protections” ← and that list depends upon what the browser detects, the website is seeking - meaning: that list, such I presented above, changes depending upon the website visited.

ChatGPT's *lengthy* response:

Brave’s “Block fingerprinting” setting is essentially a collection of defenses against scripts that try to uniquely identify your device. What you’re seeing now - the dynamic list of protections - is Brave exposing which fingerprinting surfaces a specific site is probing and how it’s responding.

The key idea: instead of just blocking APIs outright (which breaks sites), Brave often normalizes, randomizes, or lies slightly about values so you blend in with a crowd.

Here’s how each item you listed fits into that:

---

Device memory

• Websites can query navigator.deviceMemory to estimate your RAM (e.g., 4GB vs 16GB).
• Fingerprinting risk: narrows down your device profile.
• Brave behavior: reports a rounded or generic value (like 4 or 8), or sometimes a fixed value shared by many users.

---

Font

• Sites can detect installed fonts via rendering tricks.
• Risk: font lists are highly unique across users.
• Brave: limits detection or returns a standardized set, preventing enumeration of your real fonts.

---

Hardware concurrency

• navigator.hardwareConcurrency reveals number of CPU cores.
• Risk: contributes to a unique fingerprint.
• Brave: caps or standardizes this (e.g., always reports a common value like 4 or 8).

---

Hardware / graphics acceleration

• This is your GPU being used by the browser.
• Important distinction:
• • Hardware acceleration = performance feature
• • Fingerprinting protection = privacy layer on top
• Risk: GPU details can identify you.
• Brave: allows acceleration but masks GPU-specific info.
• Your earlier observation is correct:
• • Some sites (especially banking or 3D rendering) require WebGL, which in turn often requires hardware acceleration ON.
• • Brave now tries to let WebGL work while still reducing fingerprinting entropy, instead of forcing you to disable protections.

---

Keyboard

• Refers to keyboard layout and input characteristics.
• Risk: layout (e.g., US vs DE) can be used for fingerprinting.
• Brave: may standardize or limit exposure of layout details.

---

Language

• navigator.language and related headers.
• Risk: uncommon language combinations can identify you.
• Brave: may reduce granularity (e.g., only en-US instead of a long preference list).

---

Media devices

• APIs can list microphones, cameras, speakers.
• Risk: device names and counts are highly unique.
• Brave: hides labels or returns generic device info unless permission is granted.

---

Screen

• Includes resolution, color depth, available screen size.
• Risk: exact screen dimensions (especially with scaling) are very identifying.
• Brave: rounds values or reports a common resolution bucket.

---

User agent

• The browser’s identity string (OS, version, etc.).
• Risk: detailed UA strings can be unique.
• Brave: may freeze or reduce detail (similar to broader browser trends).

---

WebGL

• A major fingerprinting surface.
• Sites can query GPU model, driver quirks, rendering differences.
• Brave: applies techniques like:
• • Masking GPU identifiers
• • Altering rendering outputs slightly
• This is why WebGL used to be tricky:
• • Turning off protections → sites work
• • Turning them on → sites might break
• Now Brave tries to simulate a consistent, non-unique GPU profile so WebGL still functions.

---

Why the list changes per site

• Brave detects which fingerprinting APIs a site attempts to access
• Then shows only the relevant protections being applied
• So:
• • A banking site → might trigger WebGL, hardware, screen
• • A tracker-heavy site → might hit fonts, canvas, media devices, etc.

---

The WebGL + Hardware Acceleration issue

Historically …

• WebGL requires GPU access
• GPU access requires hardware acceleration ON
• Privacy tools often blocked or degraded WebGL
• Result: broken logins or verification flows (common with banks)

What has changed …

• Brave now decouples usability from identifiability
• You can:
• • Keep hardware acceleration ON (for compatibility)
• • Keep fingerprinting protection ON (for privacy)
• Brave intercepts the identifying parts instead of disabling the feature entirely

---