GPU của MacBook chạy bao nhiêu % chỉ để vẽ cái giao diện trong suốt đó? Mình đã đo, và bất ngờ

Tuần đầu sau khi cài macOS Tahoe, mình mở Activity Monitor theo thói quen — và thấy WindowServer đang ăn 20–30% CPU không rõ lý do. Mình không render video, không xuất file, không app nào chạy nặng. Chỉ để máy nhìn. Cái giao diện kính trong suốt đó đang làm gì vậy?

Câu hỏi đó dẫn mình vào một mớ phân tích kỹ thuật khá dày — từ cách Apple mô phỏng định luật khúc xạ ánh sáng trong GPU cho đến một lỗi từ nhiều năm trước mà không ai để ý, đang gây ra phần lớn sự giận dữ về "Tahoe làm chậm máy". Bài này là tổng hợp những gì mình tìm được.

Kính lỏng vẽ gì trong lòng GPU

Liquid Glass không phải chỉ "làm mờ cái thanh menu một chút". Đây là một hệ thống mô phỏng vật liệu gồm nhiều lớp tính toán chạy đồng thời — và mỗi lớp có chi phí tính toán GPU riêng.

Ánh sáng bị bẻ cong theo công thức toán học

Lớp đầu tiên là khúc xạ ánh sáng — mô phỏng cách kính thực bẻ cong đường truyền ánh sáng theo định luật Snell (n₁·sinθ₁ = n₂·sinθ₂). Khi bạn cuộn nội dung bên dưới một bảng kính trong giao diện, chương trình đổ bóng (shader) trên GPU tính toán vector dịch chuyển tọa độ lấy mẫu — tức là dịch chuyển "điểm nhìn" vào nội dung nền theo công thức suy giảm parabol: offset = k·r², với r là khoảng cách chuẩn hóa từ tâm ra rìa. Mức biến dạng cực đại ở các cạnh cong của cửa sổ — giống hệt cách kính thực uốn ánh sáng tại viền (theo phân tích shader Metal của Victor Baro, Medium 2025).

Thêm vào đó là hiệu ứng sắc sai — tái tạo hiện tượng tán sắc ánh sáng qua lăng kính. Shader lấy mẫu riêng ba kênh màu đỏ, xanh lá, xanh dương với các hệ số dịch chuyển khác nhau, tỉ lệ theo cường độ biến dạng k. Viền cửa sổ vì thế có hiện tượng "nhòe màu" tinh tế — chính xác như kính thực.

Phản chiếu không cần dò tia sáng

Nhiều người đồn Liquid Glass dùng ray tracing để tạo phản chiếu. Không đúng. Ray tracing với độ phân giải giao diện toàn hệ thống sẽ làm cạn pin trong vài giờ — Apple không dùng nó cho giao diện.
Thực tế, phản chiếu trong Liquid Glass được xây dựng từ ba thứ: lọc mờ Gaussian thời gian thực chạy trên GPU, bản đồ môi trường, và dải chuyển màu. Phản chiếu thay đổi động theo con trỏ chuột, hướng kéo cửa sổ, cảm biến gia tốc trên iPhone/iPad — nhưng tất cả là phép gần đúng thông minh, không phải mô phỏng vật lý đầy đủ. SwiftUI còn cung cấp kiểu gương phản chiếu (Mirror Pattern) để tạo bóng phản chiếu bên dưới phần tử giao diện: lật ngược bản sao (scaleY(-1)) rồi áp dải mờ dần trong khoảng 30% chiều cao — không cần viết shader riêng cho từng ứng dụng.

Khi hai nút bấm "chảy" vào nhau

Đây là kỹ thuật ít được nhắc đến nhất nhưng lại tốn tài nguyên tính toán nhiều nhất: Trường khoảng cách có dấu (Signed Distance Fields — SDF). Khi hai phần tử giao diện tiến lại gần nhau — menu nổi, popup, nút bấm — thay vì gộp thô cứng, hệ thống áp toán tử hợp nhất mượt (Smooth Union):
smoothMin(d₁, d₂, k) — trong đó d₁, d₂ là khoảng cách từ điểm ảnh đến hai biên hình học, và k quyết định "độ nhớt" của vùng chuyển tiếp. GPU phải tính toán điều này liên tục theo từng khung hình trong suốt mọi hoạt ảnh chuyển đổi — đây là phần tốn chi phí tính toán nhất trong toàn bộ Liquid Glass.

Tất cả các lớp trên — khúc xạ, sắc sai, phản chiếu, SDF — đều được WindowServer thu gom, tổng hợp và đổ vào vùng đệm khung hình cuối cùng trước khi đưa ra màn hình. Metal 4 hỗ trợ quy trình này qua hàng đợi lệnh MTL4CommandQueue — giảm chi phí xử lý cho CPU, biên dịch shader trước khi chạy, dùng bảng đối số thay vì liên kết tài nguyên thủ công để giảm dấu chân bộ nhớ GPU. Về kiến trúc, đây là hệ thống được tối ưu khá tốt.

Vậy con số thực ra sao?

Dưới 1% hay hơn 50% — phụ thuộc vào ai đang hỏi

Đây là phần làm câu hỏi "Liquid Glass tốn bao nhiêu GPU?" trở nên thú vị. Cùng một câu hỏi, ba nhóm người dùng cho ba đáp án hoàn toàn khác nhau.
[IMG]

M3, M4 — Apple nói đúng trong trường hợp này

Trên chip M3 và M4, chạy ứng dụng gốc không có xung đột phần mềm, GPU của WindowServer chỉ dưới 1%. Công suất điện khi nghỉ tăng nhẹ từ 7–9W lên 9–15W — phần lớn đến từ lập chỉ mục nền sau khi nâng cấp, không phải hiệu ứng kính. Tuyên bố của Apple rằng tác động đến pin "dưới 2% ở điều kiện tiêu chuẩn" (theo Apple, tài liệu thiết kế WWDC 2025) — con số thực đo xác nhận điều đó, ít nhất là trong điều kiện lý tưởng.

M1, M2 — từ 10 giờ xuống 2 giờ, không phải ngẫu nhiên

Trên MacBook Air M1, trong tuần đầu sau khi cài Tahoe 26.0, nhiều người dùng chỉ đạt 2 giờ pin — giảm từ mức ổn định 10 giờ trên Sequoia. Sau bản 26.1, một số máy phục hồi về 12 giờ (theo OSX Daily). Nhưng không phải tất cả — một phần người dùng vẫn báo cáo 2–4 giờ dù đã cập nhật. MacBook Pro M1 Pro cũng ghi nhận pin từ 6 giờ xuống còn 3–4 giờ (theo Reddit/MacRumors).
Tại sao M1/M2 bị nặng hơn M3/M4? Hai lý do chồng chéo: các đơn vị xử lý đồ họa chuyên biệt trong M3/M4 xử lý lọc mờ và tổng hợp cảnh hiệu quả hơn nhiều so với thế hệ đầu. Và dù Apple tuyên bố máy cũ tự chuyển sang chế độ kết xuất đơn giản hóa, các phép đo thực tế cho thấy chuyển đổi này không đầy đủ — máy vẫn cố gắng render một phần hiệu ứng kính.

Intel — đây mới là "thảm họa" đúng nghĩa

MacBook Pro Intel thế hệ 2019–2020 vẫn còn được hỗ trợ macOS Tahoe. Và đây là nơi Liquid Glass gây ra thiệt hại thực sự — GPU phải chạy hết công suất qua WindowServer chỉ để bắt kịp việc vẽ cửa sổ.
Lý do kỹ thuật: kiến trúc Intel yêu cầu truyền dữ liệu kết xuất qua khe kết nối PCIe — với độ trễ cao — từ CPU sang GPU để tổng hợp cảnh. Liquid Glass liên tục gây tắc nghẽn băng thông truyền tải đó. Kết quả: quạt tản nhiệt quay tối đa, âm thanh rè hoặc đứt quãng, giao diện phản hồi rất chậm. Một số máy thực sự không dùng được bình thường sau bản 26.3.1 (theo báo cáo trên Reddit). Không phải "hơi chậm hơn" — mà là thực sự hỏng về trải nghiệm.

Thủ phạm thật — không phải cái kính trong suốt đó

Nếu GPU của WindowServer chỉ dưới 1% trên M3/M4 khi chạy ứng dụng gốc, tại sao rất nhiều người dùng M3 vẫn phàn nàn về máy chậm và nóng? Câu trả lời nằm ở hai cái tên rất quen thuộc.

Một hàm API nội bộ từ nhiều năm trước — và cái giá phải trả

Framework Electron - nền tảng của Slack, Discord, VS Code, Figma, Spotify — đã dùng một hàm API nội bộ của AppKit có tên _cornerMask trong nhiều năm để vẽ góc bo tròn và bóng đổ cho cửa sổ. Hàm này không nằm trong tài liệu chính thức của Apple — là loại "cửa hậu" mà nhiều framework hay dùng khi cần tùy chỉnh sâu vào hệ thống vẽ cửa sổ.

Trên mọi phiên bản macOS trước đây, cách làm này hoạt động ổn. Dù vậy, macOS Tahoe thay đổi hoàn toàn cách WindowServer vẽ và tổng hợp cửa sổ để phục vụ các hiệu ứng khúc xạ, thấu kính rìa và bóng đổ phân tầng của Liquid Glass.

Cơ chế lỗi được giải thích rõ trong bản vá chính thức của Electron (theo Electron GitHub, PR #48376): AppKit kiểm tra — "Hàm _cornerMask này có từ bộ khung cửa sổ chuẩn không?" Nếu có → coi mặt nạ là tĩnh, dùng bộ nhớ đệm dùng chung. Nếu không → coi mặt nạ là động, tính lại theo từng cửa sổ mỗi khung hình. Vì Electron đã ghi đè hàm này, AppKit luôn trả lời "không" — đẩy WindowServer vào vòng lặp tính toán và vẽ lại toàn bộ hệ thống bóng đổ xung quanh mỗi cửa sổ Electron mỗi lần hiển thị.

CPU của WindowServer vọt lên hơn 50%, hộp thoại lưu và mở tệp đứng đơ, giao diện hệ thống giật ngay cả trên M4. Đây là lý do phần lớn những người dùng M3/M4 cũng thấy máy chậm — không phải do Liquid Glass, mà do Slack hay Discord chưa cập nhật.

Đã fix — nhưng cần đúng phiên bản

Electron đã fix triệt để trong các phiên bản 36.9.2, 37.6.0 và 38.2.0 — bằng cách gỡ bỏ hoàn toàn _cornerMask và trả ứng dụng về đường kết xuất tiêu chuẩn của macOS (theo AppleInsider, 10/2025). Slack và Discord đã cập nhật lên các phiên bản Electron đã vá. VS Code có chu kỳ cập nhật riêng — cần kiểm tra changelog để xác nhận phiên bản nào đã có fix.

Nếu bạn đang dùng bất kỳ app nào trong số này và chưa cập nhật, đây là bước quan trọng nhất cần làm trước khi thử bất cứ giải pháp nào khác.

Chrome — nguồn gây quá tải thứ hai

Khi tính năng tăng tốc phần cứng của Chrome được bật, trình duyệt gửi liên tục các tác vụ kết xuất từ mọi thẻ đang mở — kể cả thẻ nền — tới bộ tổng hợp cảnh của hệ điều hành. WindowServer phải thực hiện một bước lọc mờ qua ranh giới cửa sổ theo thời gian thực để vẽ lớp Liquid Glass phía trên nội dung Chrome.

Màn hình ngoài 4K hay 5K làm tình hình tệ hơn gấp bốn lần — số điểm ảnh cần xử lý tăng theo bình phương, băng thông bộ nhớ GPU bị chiếm dụng nặng. Hệ quả thấy rõ: trễ gõ phím trong ứng dụng Ghi chú, hoạt ảnh hệ thống giật ngay cả trên M3 — dù bản thân GPU của WindowServer về mặt kỹ thuật không làm gì sai.

Thay đổi ẩn trong kiến trúc — và cái khiến giới nghiên cứu khoa học nổi điên

Có một thay đổi bên dưới macOS Tahoe mà hầu hết người dùng thông thường không biết đến — nhưng nó ảnh hưởng nghiêm trọng đến một cộng đồng người dùng rất đặc thù: các nhà nghiên cứu dùng Psychtoolbox trên Matlab và Octave cho các thí nghiệm tâm lý học và thần kinh học.

Apple dịch chuyển thời hạn hoàn thành của bộ tổng hợp cảnh — từ vị trí sát cuối khung hình lên gần đầu khung hình. Lý do kỹ thuật hợp lý: GPU cần thêm thời gian để hoàn tất các phép tính Liquid Glass nặng trước khi chu kỳ VSync tiếp theo bắt đầu. Nhờ đó giao diện chạy mượt 60fps/120fps trên màn hình ProMotion — GPU biết thời hạn sớm và chuẩn bị kịp.

Hệ quả không ngờ lại là: ứng dụng nhận được tín hiệu xác nhận "khung hình đã hiển thị" chỉ ở đầu chu kỳ tiếp theo — và chỉ còn chưa đến 1 mili-giây để chuẩn bị khung hình kế tiếp trước thời hạn mới. Psychtoolbox — vốn dựa vào đồng bộ VSync chính xác để trình bày kích thích thị giác đúng thời điểm — liên tục bỏ lỡ thời hạn: 599 trong số 600 lần hiển thị thất bại, tốc độ khung hình thực tế chỉ đạt 30fps trên màn hình 60Hz (theo diễn đàn Psychtoolbox, 2026).

Developer Mario Kleiner của Psychtoolbox xác nhận nguyên nhân chính xác là sự dịch chuyển thời hạn của bộ tổng hợp cảnh — và macOS Tahoe hiện chưa được khuyến nghị cho thí nghiệm đòi hỏi định thời chính xác (theo Psychtoolbox forums). Lỗi xuất hiện trong log: PsychVulkanCore-ERROR: vkWaitForPresentKHR(1): Failed due to timeout!

Bài học: thay đổi ở cấp bộ tổng hợp cảnh có những hậu quả vượt xa phạm vi giao diện người dùng — và không phải lúc nào Apple cũng thông báo rõ ràng những gì thay đổi bên dưới.

Fix theo thứ tự — cái nào làm trước

Dưới đây là những gì thực sự có tác dụng, xếp theo mức độ ưu tiên:

1. Cập nhật ứng dụng Electron ngay — đây là ưu tiên số một

Nếu đang dùng Slack, Discord, VS Code, Figma hay Spotify — mở từng app và cập nhật lên phiên bản mới nhất. Electron 36.9.2+, 37.6.0+, 38.2.0+ đều đã có fix cho lỗi _cornerMask. Đây là nguồn gây quá tải lớn nhất và bước này xóa sạch vấn đề mà không cần can thiệp thêm gì (theo AppleInsider).

2. Bật Giảm độ trong suốt

Khi bật, WindowServer ngừng ngay lập tức việc tính toán lọc mờ Gaussian động và các hiệu ứng uốn cong ánh sáng tại biên cửa sổ — tải GPU và CPU giảm xuống mức tối thiểu trong vài giây. Máy mát hơn, mượt hơn rõ rệt, đặc biệt trên M1/M2.

Lưu ý quan trọng: tính năng này bị lỗi mã nguồn nghiêm trọng trên Tahoe 26.1 và 26.2 — dù đã bật, giao diện vẫn trong suốt và không tiết kiệm tài nguyên gì cả. Phải nâng cấp lên ít nhất Tahoe 26.3 mới hoạt động đúng (theo OSX Daily, 02/2026).

Đường dẫn: Cài đặt hệ thống → Trợ năng → Màn hình → Bật Giảm độ trong suốt

3. Bật Giảm chuyển động

Thay các hoạt ảnh co giãn dạng lỏng phức tạp bằng chuyển cảnh mờ dần đơn giản — giảm đáng kể số khung hình trung gian cần tính toán, đặc biệt có ích trên M1/M2 khi mở Control Center hay kéo cửa sổ.

Đường dẫn: Cài đặt hệ thống → Trợ năng → Chuyển động → Bật Giảm chuyển động

4. Tắt tăng tốc phần cứng trong Chrome

Vào chrome://settings/system và tắt tùy chọn tăng tốc phần cứng. Chrome chuyển sang dùng CPU để kết xuất — cô lập hoàn toàn khỏi quy trình kết xuất của WindowServer. Con trỏ chuột hết giật, hoạt ảnh hệ thống trở lại bình thường. Đánh đổi: Chrome chậm hơn chút ở một số tác vụ đồ họa trong trình duyệt — nhưng với đa số người dùng thông thường, không có gì đáng chú ý.

5. Biến môi trường Electron (khi vẫn còn xung đột)

Nếu sau khi cập nhật app Electron mà WindowServer vẫn cao bất thường, chạy lệnh này trong Terminal rồi khởi động lại các app:

launchctl setenv CHROME_HEADLESS 1

Lệnh này buộc nhân Chromium nội bộ ngừng yêu cầu WindowServer kết xuất bóng đổ phức tạp xung quanh hộp thoại — loại bỏ điểm nghẽn GPU gây đứng hàng đợi tệp tin.

6. Khởi động lại WindowServer khi bị đứng đột ngột

Khi cửa sổ hệ thống hoặc hộp thoại lưu tệp đứng đơ sau nhiều giờ làm việc liên tục, lệnh này khởi động lại bộ tổng hợp cảnh mà không cần tắt máy — dọn sạch vùng nhớ bị rò rỉ và hàng đợi kết xuất bị nghẽn:

sudo killall -HUP WindowServer

Lưu ý: máy sẽ tạm thời đăng xuất — lưu công việc đang làm trước khi chạy lệnh này.

Vậy thì câu trả lời cho câu hỏi ban đầu là gì? Liquid Glass về mặt kỹ thuật không phải kẻ phá máy. Trên M3/M4 không có xung đột phần mềm, GPU của WindowServer chỉ dưới 1% — đúng như Apple tuyên bố. Kiến trúc Metal 4 đủ thông minh để tối ưu một quy trình quang học khá phức tạp xuống mức không đáng kể cho phần cứng hiện đại.

Vấn đề thực đến từ nơi khác: một hàm API nội bộ từ nhiều năm trước bị ghi đè không đúng chỗ, một trình duyệt gửi quá nhiều tác vụ kết xuất lên bộ tổng hợp cảnh, và một thế hệ phần cứng Intel đã đến giới hạn thực sự với kiến trúc giao diện mới này. Nếu đang dùng M1/M2 và thấy pin hao nhanh hơn bình thường, bước đầu tiên không phải là đổ lỗi cho giao diện kính — mà là kiểm tra xem Slack hay Discord đã cập nhật đúng phiên bản chưa.

Nếu đang cân nhắc nâng lên MacBook Pro M5 hay MacBook Air M5 để thoát khỏi những vấn đề này, mình hay hỏi thêm ở macone.vn — chỗ này tư vấn cấu hình khá thật, không ép mua bản cao hơn nếu nhu cầu thực tế không cần.

Anh em đang dùng chip gì và có thấy Tahoe ảnh hưởng đến pin hoặc hiệu năng không? Đặc biệt tò mò xem những bạn dùng M1/M2 — sau khi cập nhật Electron apps, tình hình pin cải thiện bao nhiêu — vì dữ liệu phục hồi khá phân tán, chưa có con số nhất quán nha.

#macos #tahoe #liquidglass #metal4 #macbook #apple #macone #windowserver