2019年12月12日 10:34:27 - update
vscode 1.40 disable-gpu-acceleration 更新了一個配置選項：
- 打開命令板 (Ctrl+Shift+P/ CMD+Shift+P / F1).
- 輸入
Preferences: Configure Runtime Arguments - 添加
"disable-hardware-acceleration": true配置項 - 重啟
此時應用啟動時默認關閉硬件加速肃弟，等同于code --disable-gpu
2019年09月04日22:18:16 - update 已fixed 只是緩解
當前版本已更新到 1.37.1 卡頓問題仍會有鸳劳，這個時候突然靈光閃現(xiàn)，去搜索了一下關閉gpu渲染的方式：
# macos
$ code --disable-gpu
首先需要完全退出vscode议泵，此時再通過禁用gpu啟動vscode贡这，之前的卡頓現(xiàn)象就徹底消失了戈泼。
經(jīng)過長時間的觀察南片，我猜測是我使用的macbook pro 集顯渲染存在問題睡陪，導致輸入延遲和掉幀寺渗，關閉gpu渲染后，整個webview不再出現(xiàn)原先嚴重的輸入延遲宝穗，算是真正的解決了開發(fā)體驗的問題（除了啟動時需要手動關閉gpu渲染）户秤。同理，先前卡頓時逮矛，開啟chrome devtool Layer borders鸡号，后卡頓現(xiàn)象消失，說明開啟該功能后须鼎，渲染會交由CPU處理鲸伴，很可能是GPU渲染出現(xiàn)了問題府蔗。
2019年07月04日12:45:53 - update
今天更新了vscode 1.36，遇到了之前出現(xiàn)的問題汞窗，現(xiàn)在不再是2k屏渲染的差異問題姓赤，嘗試單屏重啟vscode，重啟電腦仲吏，仍會有相當大的輸入響應延遲不铆。
重裝1.35.1版，問題消失裹唆。接著嘗試安裝insider版本誓斥，同樣出現(xiàn)了卡頓。
比對多幾個版本vscode的內(nèi)置版本情況：
Code/1.35.1 Chrome/66.0.3359.181 Electron/3.1.8
Code-Insiders/1.36.0-insider Chrome/69.0.3497.128 Electron/4.2.5
再回看之前的記錄许帐，最早出現(xiàn)在68升級到69時候劳坑，出現(xiàn)這個問題，比對今天的情況成畦，基本可以確定問題是Chrome69存在這一個問題距芬。
按之前后續(xù)的體驗來看，目前只能等vscode多更新幾個electron版本循帐，至少要在chrome71以后才得到解決框仔。
2018年12月19日11:47:51 - update
經(jīng)過一段時間使用，發(fā)現(xiàn)可能chrome卡頓可能是macos帶來的問題惧浴，已復現(xiàn)問題存和。
我的設備是一臺macbook + 外接2k屏。
復現(xiàn)場景：
當外接2k屏時衷旅，啟動基于chromium的程序捐腿，比如vscode 或者chrome，開啟后柿顶，用戶輸入的響應會被延遲到400 ~ 1000ms茄袖，即下文截圖中的performance的紫色寬度條。這個時候整個程序的渲染都是非赤揖猓卡頓的宪祥。此時拔掉顯示器線，依然是卡頓的情況家乘。
未接入2k屏時蝗羊，啟動程序時，渲染則是正常的仁锯，此時再接上外屏耀找，程序也是正常的。
現(xiàn)在不清楚是chrome在啟動時业崖，獲取了顯示器參數(shù)來處理輸入事件還是什么原因?qū)е铝诉@個問題野芒。
ps. 需要注意蓄愁，macos下關閉窗口不等于關閉程序，只要保證啟動程序時狞悲，不接入外屏撮抓，之后使用中，只要不完整退出程序（退出后dock上不顯示）摇锋，就能保證程序正常使用丹拯。
版本
MacOS: 10.13.14
MacBook Pro 2017 無touch-bar
chrome版本 69.0.3497.92（正式版本） （64 位）
最近chrome69更新，第一時間我就從68更新到了69乱投，緊接著就出現(xiàn)了瀏覽器整體卡頓的問題咽笼。
這個卡頓表現(xiàn)在顷编，外接2k顯示屏情況下戚炫，chrome在外接屏上整體幀數(shù)比mac內(nèi)屏上少20幀，滾動頁面時明顯感覺到卡頓媳纬。google了半天后双肤，沒有搜到什么有用的資料。
開啟開發(fā)者工具钮惠，使用performance錄制卡頓和非卡頓時的表現(xiàn)可以發(fā)現(xiàn),interaction下的scroll update耗時相差了100~200ms左右茅糜。
緊接著，嘗試重裝68素挽，68下chrome沒有出現(xiàn)雙屏時表現(xiàn)不一致的情況蔑赘。而且chrome自更新也讓我放棄了繼續(xù)折騰。再換了n個關鍵詞后预明，搜到一個chrome 提供了硬件加速的選項缩赛，關閉之后，問題得到了解決(chrome 69)撰糠，恢復了正常酥馍。
然而過了兩天后，類似的事情又發(fā)生了阅酪，這次略有不同旨袒，僅在公司后臺web項目下，外屏的頁面只有不到5幀术辐，而且在項目的tab下砚尽，整個瀏覽器也出現(xiàn)了卡頓，切換到其他頁面就沒有這個情況辉词。
同樣的問題必孤，也是搜索了半天，仍然得不到解決较屿。昨晚突然想起隧魄，硬件加速關閉了卓练，重新打開硬件加速，頁面又恢復了流暢购啄，非常的迷襟企。
這里放一些performance的截圖，后面的截圖狮含，前本段是內(nèi)屏顽悼，后半段是外屏，可以看紫色條寬度對比：
可以看到几迄，主線程存在堵塞的情況蔚龙，交互發(fā)生后，等待主線程超過了100ms映胁，而每一次滾動鼠標滾輪木羹，觸摸板或者其他交互，均會因為主線程堵塞被拖長執(zhí)行時間解孙，我猜測可能是chrome在不同屏幕分辨率下的調(diào)用策略不同坑填，同時由于之前關閉了硬件加速(GPU加速)，導致頁面的渲染全部交由主線程(CPU)處理弛姜，一旦主線程出現(xiàn)卡頓或者處理延遲脐瑰，整個渲染就被延后。現(xiàn)在重新開啟了硬件加速廷臼，這部分問題得到了緩解苍在，但是從性能上看，依然是存在一些問題的荠商，但延遲降低到了100ms以下寂恬，幀率相比之前的卡頓起碼能恢復到60幀，而不是全程5幀结啼。
雖然問題暫時得到了解決掠剑，不知道之后還會不會出現(xiàn)類似的問題军拟，這次的問題缆蝉，希望未來能夠?qū)W會到如何提bug給google，或者參與到更大的開源項目中草巡。
