更新速度很慢是因為CPU的編譯太慢了
我始終接受不了在我這裡的firefox性能需求很高。 於是我就最近跳到Thorium Browser AVX，(Chrome)。
但是我真的太過好奇為什麼會有這個問題啊. 我決定去搜尋，我看到了一個網站有人這麼做#3， 於是我決定自己去分析(使用Ai工具補助分析)
你們可以看這個:https://share.firefox.dev/4qDIH7d
PS:這是我單獨開一個設定檔去測試的，什麼設定都沒有修改。
Environment:
- OS: Arch Linux
- Resolution: 1920x1080 60hz, 2560x1440 75hz
- DE: KDE Plasma 6.5.5 (Wayland)
- WM: kwin_wayland_wr
- CPU: E3-1230 v2 (Ivy Bridge)
- GPU: AMD Radeon RX Vega 64 (radeonsi, vega10, ACO, DRM 3.64, 6.18.5-1-cachyos)
- Browser: Firefox 147 (Parent Process)
about:support:
- Compositing WebRender
- Window Protocol wayland
- Desktop Environment kde
- Target Frame Rate 60
初步觀察amdgpu_top 顯示滑鼠移動時 CPU劇增。
滑鼠不移動:0%。
滑鼠移動:
- 125Hz:10~14%。
- 250Hz:23~28%。
- 500Hz:34~42%。
- 1000Hz:48~55%)，
ALL GPU(GFX) Usage為0%。
對照：同樣硬體，Chromium 核心無此問題#4。
滑鼠不移動:0%。
滑鼠移動:
- 125Hz:1~3%。
- 250Hz:1~3%。
- 500Hz:1~3%。
- 1000Hz:1~3%。
ALL GPU(GFX) Usage為0%。
PS:根據我的測試不管用什麼firefox的分支 or 官方最新的遊覽器(Firefox、LireWolf、Zen Browser)都是一樣。
可惜我沒有其他的硬體設備可以測試問題 是否是單一性問題還是Firefox程式問題...
證據：Firefox Profiler 顯示主執行緒被 handleEvent 塞滿，且大量的時間消耗在 IPC 通訊 與 Event Dispatching。
EventListener.handleEvent
handleEvent chrome://browser/content/browser.js:4157:14
forEach self-hosted:4110:20
Set.prototype.values
---2026/02/15---
mouse: 1000hz。
第一版的patch確定可以減少了。
mouse.throttle.enabled=true
mouse.throttle.interval=
- 1: 35~37%
- 8: 11~13%
- 20: 10~12% 可以使用。
- 100: 8~9% Firefox GUI明顯延遲。
PS:system mouse沒有影響。只影響GUI。影響就是你用滑鼠按住複製會有影響，變得變得明顯反應很慢。
$$1000ms \div 60 \approx 16.67ms$$建議數值：16 或 17。
設定為 16 的優點：理論頻率約 62.5Hz，略高於螢幕刷新率，能確保滑鼠軌跡在螢幕更新前就已經準備好數據，體感上會最接近「無延遲」。
設定為 17 的優點：優點：理論頻率約 58.8Hz，比 60Hz 慢一點點，對 CPU 壓力最輕，但對於極度敏感的人來說，可能會感覺滑鼠稍微有一點點跟不上螢幕（極微小）
---2026/02/16---
我發現到第二版的patch可能會有問題，雖然當初考量到精度把mLastMouseCoordinates.Set(aEvent) 被放在函式的最頂端，但是問題就是造成的CPU不斷刷新。
目前現況總結 (Summary of Discoveries)
效能瓶頸確認 (Performance Bottleneck)：
在之前的 Patch 中，
mLastMouseCoordinates.Set(aEvent)被放在函式的最頂端（大門口）。這導致在高回報率滑鼠（1000Hz）下，CPU 每秒必須強行執行 1000 次座標轉換與物件更新。
Profiler 證據：你在截圖中看到的密集彩色波峰，就是這些高頻率、小規模的運算堆疊而成的結果，這會讓
Parent Process持續處於忙碌狀態。
節流與合併的權衡 (Throttling vs. Coalescing)：
丟棄模式 (Throttling)：不執行
Set直接返回。最省 CPU，但可能導致 16ms 內位置資訊完全跳躍。合併模式 (Coalescing)：即使節流也先執行
Set。這確保了「最後已知座標」永遠是最新的，雖然多了一點開銷，但能維持瀏覽器內部的座標狀態（State）正確。
手寫筆精度風險 (Stylus Risk)：
現有 Patch 預設對所有設備節流。如果使用手寫筆進行繪圖，每 16ms 才取一個點會導致線條變形（失真）。
代碼中雖然有
IsPenEvent檢測，但尚未與節流邏輯連動。
後續測試計畫 (Testing Plan)
為了驗證上述推論，我們將測試以下三個階段的 Patch，建議你依照順序編譯並觀察 Profiler：
驗證節流有效性 (Fix 1: Basic)：
動作：將
Set移入判斷式之後。預期：彩色波峰會大幅稀疏化，CPU 佔用率降至最低。
驗證合併開銷 (Fix 2: Coalesce Option)：
動作：開啟
mouse.throttle.coalesce = true。預期：彩色波峰會比 Fix 1 密一點，但仍遠低於沒打補丁的狀態。
驗證白名單邏輯 (Fix 3: Pen Bypass)：
動作：使用「日誌列印法」或「邏輯反轉法」確認滑鼠不會誤入 Pen 邏輯。
預期：確保未來接入高精度設備時不會發生精度 Regression。
