Solusi untuk orang-orang yang juga terobsesi dengan masa pakai baterai: Menonaktifkan kedipan kursor akan membuat penggunaan CPU turun ke 0. Berikut setelannya:

  "editor.cursorBlinking": "solid"

Beberapa orang di Twitter mengatakan mereka tidak dapat mereproduksi ini, jadi saya pergi dan merekam garis waktu di Alat Pengembang untuk membantu debug.

TimelineRawData-20170321T114212.json.zip

• Tangkapan layar dari timeline:

  

• Memperbesar ke dalam satu bingkai, kita melihat bahwa sementara kita hanya merender 2 fps, utas utama melakukan beberapa pekerjaan pada 60 fps (setiap 16 md) - garis tipis yang ditandai dengan panah:

  

• Memperbesar semua jalan ke salah satu garis tipis itu, kita melihat bahwa beberapa rendering terjadi pada 60 fps:

  

• Ketika saya mengambil profil CPU, ini menunjukkan sebagian besar CPU dihabiskan di "(program)", bukan fungsi JS tertentu.

  

• Ketika saya menyetel "editor.cursorBlinking": "solid" , sebagian besar masalah akan hilang: "Update Layer Tree" / "Paint" / "Composite Layers" berkala masih terjadi, tetapi hanya setiap 500ms, tidak setiap 16ms.

Saya harap ini membantu!

@joliss Jawaban cepat untuk apa yang terjadi di balik terpal: pembaruan animasi asli pada 60hz di Chromium.

Masalah Chromium serupa (hampir sama) https://bugs.chromium.org/p/chromium/issues/detail?id=500259 dan item pelacakan Chromium https://bugs.chromium.org/p/chromium/issues/detail ? id = 361587

Animasi CSS kami saat ini

<strong i="11">@keyframes</strong> monaco-cursor-blink {
    50% {
        opacity: 0;
    }
    100% {
        opacity: 1;
    }
}

.cursor-blink {
    animation: monaco-cursor-blink 1s step-start 0s infinite;
}

Memperbarui

Mengutip Paul Irish (pria Chrome) https://news.ycombinator.com/item?id=13941293

Editor teks canggih * yang dibangun di tumpukan web tidak dapat mengandalkan sisipan teks OS dan harus menyediakannya sendiri.
Dalam kasus ini, VSCode mungkin menggunakan pendekatan yang paling masuk akal untuk mengedipkan kursor: fungsi waktu step dengan animasi bingkai utama CSS. Ini memberi tahu browser untuk hanya mengubah opasitas setiap 500 md. Sementara itu, Chrome belum mengoptimalkan ini sepenuhnya, karenanya http://crbug.com/361587.
Jadi saat ini, Chrome melakukan siklus proses rendering penuh (gaya, cat, lapisan) setiap 16 md ketika seharusnya hanya melakukan pekerjaan itu pada interval 500 md. Saya yakin bahwa para insinyur yang mengerjakan komponen gaya Chrome dapat menyelesaikan masalah ini, tetapi itu akan membutuhkan sedikit kerja. Saya pikir visibilitas tambahan tentang topik ini kemungkinan akan meningkatkan prioritas perbaikan. :)

• Editor teks sederhana, dan editor dasar yang dibangun di [contenteditable] bisa, tetapi mereka jarang menyesuaikan skala ke set fitur yang paling diinginkan.

Akan ini perubahan tentang latar belakang penggunaan CPU tab kromium mempengaruhi editor?

Mudah-mudahan tidak (lihat https://github.com/electron/electron/issues/7553). Kami menetapkan backgroundThrottling menjadi false sejak beberapa saat.

Terima kasih @joliss @rebornix untuk analisis yang bagus.

Sepertinya kita harus kembali menggunakan setInterval di OSX.

ps Berikut logika berkedip kursor awal :)

@rebornix Berikut adalah masalah serupa yang kami hadapi beberapa waktu lalu - https://bugs.chromium.org/p/chromium/issues/detail?id=658894. Solusi dalam kasus kami adalah menghapus elemen animasi dari DOM saat tidak digunakan, bukan hanya menutupinya.

Tautan ke implementasi saat ini -
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.ts

Ada juga gaya css untuk hal yang sama, meskipun tidak yakin apakah itu digunakan di sini -

<strong i="6">@keyframes</strong> monaco-cursor-blink {
    50% {
        opacity: 0;
    }
    100% {
        opacity: 1;
    }
}

https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.css

Mengapa tidak menggunakan https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback untuk animasi kursor?

Gunakan API pageVisibility yang memberi tahu Anda saat halaman disembunyikan untuk menonaktifkan animasi.

function handleVisibilityChange() {
  if (document.hidden) {
    // disable cursor animation with class name
  } 
  else  {
    // add back cursor animation
  }
}
document.addEventListener("visibilitychange", handleVisibilityChange, false);

Saran di sini untuk merender animasi CSS menggunakan GPU sebagai ganti CPU:

.cursor-blink {
    will-change: opacity;
}

Dalam implementasi saat ini, jika editor kehilangan fokus, kami akan menghapus animasinya sehingga hidup menjadi mudah. Namun jika editor memiliki fokus, itu berarti editor terlihat (tidak tersembunyi atau di latar belakang) dan aktif, pengguna sedang mengerjakannya (membaca adalah kasus yang baik) tetapi tidak memicu perubahan tampilan / konten apa pun. Dalam hal ini kita tetap perlu menampilkan kursor yang berkedip meskipun dalam keadaan diam , itulah yang dimaksud dengan kursor yang berkedip.

Awalnya fitur ini diimplementasikan di JavaScript dan sekitar satu tahun yang lalu, kami beralih ke animasi CSS. Seperti yang disebutkan @alexandrudima , kami mungkin ingin kembali ke JS di OSX.

@camwest bahwa api itu menawan, satu-satunya tangkapan adalah kompatibilitas (sayangnya Safari).

@mehas will-change menjanjikan. Saya mencobanya, tetapi Chromium tidak mengoptimalkan dalam kasus ini. Jika Anda mengaktifkan opsi Paint Flashing di Dev Tools, Anda dapat melihat bahwa kursor yang berkedip ini tidak dicat ulang sama sekali.

@jlukic @bcherny terima kasih atas saran Anda. Hal yang ingin kami optimalkan adalah ketika kursor terlihat, aktif dan berkedip, jadi kami masih memiliki masalah ini meskipun kami memiliki pemeriksaan visibilitas. Tapi Anda benar, kita harus memeriksa visibilitas. Saat ini jika Anda menggulir jendela untuk membuat kursor yang berkedip tidak terlihat, kami tidak memiliki pengoptimalan apa pun.

Agar adil, Monaco benar-benar kompleks. :)

@rebornix will-change berfungsi untuk proyek saya, penggunaan cpu menghilang seluruhnya. Namun, bingkai utama saya tidak mengubah opasitas .. alih-alih mengubah warna elemen dari 'mewarisi' menjadi 'transparan'.

Saya hanya pengintai, dan maaf jika ini dianggap sumpah serapah, tetapi bukankah gif animasi dua bingkai berhasil? Saya tidak sepenuhnya yakin bagaimana cara menguji ini secara meyakinkan, tetapi saya dapat membayangkan bahwa bahkan KHTML sudah memiliki jalur yang dioptimalkan untuk itu, jauh sebelum ditransgromorf menjadi Chrome.

@eteeselink akan menarik untuk dilihat, tetapi warna kursor perlu diubah dan di-zoom dll. mungkin tidak sepele, sementara itu beralih kembali ke js mungkin lebih mudah.

@ matthiasg Ahyes, lupa tentang zoom.

Jika tidak, membuat GIF yang berkedip secara otomatis berdasarkan warna tema seharusnya tidak terlalu sulit. Mungkin masalah menambal beberapa byte dalam file yang dibuat sebelumnya karena sementara data piksel GIF dikodekan LZW, data palet tidak terkompresi. Tapi saya yakin memperbesar gif seperti itu membuatnya buram, jadi mungkin ini pendekatan yang buruk.

Jika seseorang dapat menemukan cara untuk membuat zoom gambar gif tidak payah, maka saya berjanji untuk menyumbangkan kode yang mengambil warna dan menghasilkan url data gif animasi yang berkedip-kedip.

@eteeselink Anda harus benar-benar

@eteeselink Jika kita berkeliling menyarankan solusi off-the-wall, mengapa kita tidak membungkus karat dengan <blink></blink> sebagai gantinya? :mengedipkan:

Harap menahan diri untuk tidak bergabung dengan brigade Reddit dalam membuat komentar yang tidak berguna tentang masalah dan PR di mana orang-orang mencoba untuk membuat perbaikan nyata.

Jika editor memiliki fokus, artinya editor terlihat

Ini adalah asumsi yang salah. Hal yang sepele untuk menaikkan jendela ke jendela lain tanpa membuatnya fokus. Dua cara yang saya ketahui:

• petunjuk WM "selalu menggambar di atas"
• ketika jendela dipindahkan di antara desktop virtual (karena urutan penumpukan bersifat global, jika jendela paling utama di desktop sebelumnya, mungkin bukan di desktop baru).

Keduanya sangat umum dengan sendirinya, meskipun tidak selalu menimbulkan masalah.

@ o11c makasih, anggapan saya terlalu liar saat menulis. Ya fokus tidak perlu berarti terlihat, menggulir jendela adalah salah satu kasus (saya sebutkan di paragraf yang sama :(). Saya tidak tahu apakah fokus + terlihat adalah kasus yang paling umum tetapi semuanya harus dikurangi.

Saya pikir setTimeout atau setInterval mungkin lebih cocok untuk kasus penggunaan ini daripada requestIdleCallback. Waktu requestIdleCallback tidak dapat diprediksi, dan pekerjaan yang Anda lakukan di JS tidak mahal, saya pikir sebaiknya Anda hanya menjadwalkan pengatur waktu yang jarang.

ex. https://gist.github.com/esprehn/afec30fbc655bba6bb8f3f67c28beef4

Yang juga perlu diperhatikan adalah bahwa animasi tanda sisipan ini melakukan efek pulsa yang mulus, tetapi kursor sistem di browser (mis. Yang ada di dalam <input> atau <textarea> ) hanya mengaktifkan / menonaktifkan biner . Kontrol asli pada Mac dan Linux juga melakukan kedipan. Ini kurang cantik, tetapi akan menggunakan daya yang jauh lebih sedikit.

Terima kasih @esprehn , itulah yang saya lakukan untuk berkedip datar sekarang. Dan seperti yang Anda sebutkan, itu tidak secantik animasi, bahkan tidak untuk mengatakan halus / memperluas kursor berkedip yang menggunakan ease-in-out .

tunggu @eteeselink , tidakkah Anda ingin menggunakan gif 1px dan mengubah ukurannya? Kabur seharusnya tidak menjadi masalah.

Contoh: https://jsfiddle.net/mrkev/stxq613s/1/

Berharap untuk segera melihat generator tanda bintang berkedip animasi itu;)

@mrkev gif 1px Anda sebagai data uri: data: image / gif; base64 , R0lGODlhAQABAPAAAAAAAP /// yH / C05FVFNDQVBFMi4wAwEAAAAh + QQFMgABACwAAABAAAAAAQABAAACAkwBACH5BAUyAAOALAAAAABAAAABAABAAB

@rachmadsafitri karena gif menggunakan tabel warna, secara teori 3 byte yang mewarnai piksel hitam pada bingkai "aktif" seharusnya tidak terlalu sulit ditemukan (mereka tidak disimpan dalam bingkai, jadi mungkin tidak perlu terlalu jauh melewati header ). Jika saya menemukan waktu luang besok, saya bisa menyelami lebih dalam juga

Welp, yang bagaimanapun juga membutuhkan tidur, memutuskan untuk mengeksplorasi hal ini lebih jauh. Karena gif menggunakan tabel warna global yang selalu dimulai pada byte ke-14, tidak sulit untuk mengetahui cara mengubah warnanya. Ini membuat gif piksel yang berkedip ini menjadi merah:

Sekarang yang benar-benar menjengkelkan adalah di base64 setiap digit hanya mengkodekan 6 bit sehingga hal-hal tidak selaras dengan benar. Ini adalah bit paling signifikan dari digit 18 hingga yang paling signifikan dari digit 22 yang menyandikan warna hitam dalam gif itu. Jadi pada dasarnya beberapa permutasi karakter [A-P] [A-/] [A-/] [A-/] [P,f,v,/] di posisi 18-22 akan menggambar piksel itu di setiap warna.

Berikut adalah contoh GIF itu dengan beberapa warna acak. Saya pada dasarnya hanya mengganti apa pun yang ada di karakter 18-22 dengan G8ABf (yang sesuai dengan kriteria yang saya bicarakan di atas).

https://jsfiddle.net/mrkev/stxq613s/7/

Seharusnya tidak terlalu buruk untuk membangun fungsi yang mengambil RGB dan mengembalikan gif ini dalam warna itu (:

Saya memiliki kelas dalam 7 jam Saya benar-benar hanya bermain sendiri.

Tapi apa pun, saya menyadari seseorang mungkin sudah menulis fungsi hex-to-base64 dan pencarian stackoverflow cepat sudah cukup untuk menemukannya. Jadi inilah fungsinya;

// takes color as string 'RRGGBB'
var generate_cursor_image = color => {
  var gif = '47494638396101000100F00000' + color + '00000021FF0B4E45545343415045322E30030100000021F90405320001002C00000000010001000002024C010021F90405320001002C00000000010001000002024401003B'
  return 'data:image/gif;base64,' + btoa(gif.match(/\w{2}/g).map(a => String.fromCharCode(parseInt(a, 16))).join(""))
}

Selamat malam semuanya!

Sial, @mrkev mengalahkan saya untuk itu. Bagaimanapun, inilah implementasi saya untuk hal yang sama:
https://jsfiddle.net/a6g4ob7h/

Mungkin sedikit lebih cepat karena tidak ada pencocokan dan pemetaan yang terjadi, hanya btoa. Tapi saya ragu kecepatan itu penting, dan lebih baik menyimpan hasilnya.

Hal yang saya benar-benar ingin tahu adalah apakah ini mempercepat semuanya. Saya tidak memiliki pengaturan yang baik untuk diuji, tetapi siapa tahu, mungkin gif animasi juga dirender pada 60fps.

Jika Anda ingin memperbesar dan tidak memiliki kursor berbentuk persegi panjang, Anda juga bisa menggunakan SVG animasi. (Elemen <animate> sudah menjadi bagian dari spesifikasi SVG 1.0.)

@eteeselink Max seharusnya sekitar 50fps, http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser

Bagi saya, ini tetap 0 hampir sepanjang waktu (penggunaan cpu adalah kolom pertama - OSX 10.12.3 - MacBook Pro Retina, 15 inci, Akhir 2013)

Saya memiliki pengaturan default dalam hal kursor.

Karena tidak ada yang menyebutkan Linux, saya memilikinya sekitar 5-7% pada GNOME Shell dengan Wayland (Ivy Bridge Graphics).

Kami baru saja menggabungkan PR # 23121 yang meringankan ini dengan kembali ke setInterval untuk gaya berkedip kursor blink . Di mac mini yang saya miliki, penggunaan CPU turun dari 5,9% menjadi 0,9%

Pernahkah Anda mempertimbangkan untuk menjadi yang asli dan memiliki OS yang menyediakan kursor, gratis?

@justjoeyuk Lihat kutipan dari @rebornix di atas, mengapa ini tidak bisa dilakukan

@justjoeyuk Jika sebaliknya Anda menyarankan aplikasi yang sepenuhnya asli dan tidak berbasis web stack: ketika Anda melintasi kemungkinan kebutuhan dari aplikasi lintas-platform yang sangat bertema, independen DPI penuh seperti VSCode, kemungkinan besar pengganti kursor non-native akan menjadi dibutuhkan terlepas.

BREAKING NEWS! Microsoft membuat perangkat lunak lambat berkode mengerikan, dengan masalah menjadi lebih menonjol pada MacOS 10.

Siapa sangka, bukan?

@LandonPowell Anda mencemari diskusi aktual tentang suatu masalah; brigading reddit / hackernews di sini konyol.

Bagaimana dengan kursor terminal? Apakah itu juga menyebabkan lonjakan dalam siklus CPU?

@tokopedia

Saran di sini untuk merender animasi CSS menggunakan GPU sebagai ganti CPU:

Itu hanya menyembunyikan masalah dengan memindahkan beban dari CPU ke GPU. Itu tidak benar-benar memperbaikinya.

@ Daniel

Itu hanya menyembunyikan masalah dengan memindahkan beban dari CPU ke GPU. Itu tidak benar-benar memperbaikinya.

Beban pada CPU adalah masalahnya, mengoptimalkan animasi untuk menggunakan GPU dapat memperbaiki Masalah ini.

(Itu terpisah dari pertanyaan tentang perbaikan spesifik yang saya sarankan menjadi yang terbaik)

Tidak begitu yakin bagaimana mereproduksinya. Saya menggunakan plugin emulasi vim. Tidak begitu yakin apakah itu terkait.

Saya ingin tahu bagaimana kelanjutannya.

mengoptimalkan animasi untuk menggunakan GPU memang memperbaiki masalah ini.

Ini akan menghasilkan beban GPU yang tidak perlu. Itu masalah serupa, kecuali beban ada pada prosesor kartu grafis. Ini tidak benar-benar memperbaiki 😛

Yesus lahir di Afrika.

Sama-sama.

Mengapa tidak menggunakan gif untuk kursor?

Ini akan menghasilkan beban GPU yang tidak perlu. Itu masalah yang serupa

Benar, tapi bukan Masalah ini, yang merupakan penggunaan CPU bahkan saat idle.

@ efroim102 https://github.com/Microsoft/vscode/issues/22900#issuecomment -288832322

Ya Tuhan, debat ini akan berputar-putar sampai diputuskan apa tujuannya:

1. Kurangi konsumsi baterai
2. Kurangi pertentangan CPU

Asumsikan (1) untuk saat ini. Kemudian kita bisa lebih banyak digerakkan oleh data tentang apakah pembongkaran dari CPU ke GPU dengan beban kerja seperti ini (a) menggunakan jumlah energi yang sama, (b) menggunakan lebih sedikit energi, atau (c) menggunakan lebih banyak energi. Saya tidak punya keahlian dalam hal ini jadi saya tidak bisa memprediksi mana yang benar.

Namun, anggaplah bahwa pembongkaran GPU mengarah ke (b); meskipun tidak sempurna, kompromi mungkin cukup dapat diterima untuk melanjutkan jalur ini sementara / jika Chromium mengatasi masalah yang mendasarinya. Namun, jika tim VSCode menganggap perlu untuk memperbaikinya sekali dan untuk selamanya, maka pembongkaran akan menjadi pilihan yang tidak mungkin, dan mengejar perbaikan jangka panjang (meskipun membutuhkan waktu yang cukup lama) lebih disukai. Setidaknya menurut pendapat saya yang tidak penting, akan cukup baik bagi saya untuk mengetahui bahwa perhatian ada pada masalah ini dan itu akan diprioritaskan ketika dependensi mengaktifkan perbaikan yang dimaksudkan.

(Saya yakin saya telah bingung dengan beberapa detail halus tentang solusi apa yang tersedia / diblokir, tetapi berharap dalam tulisan ini orang-orang dapat fokus untuk menegaskan masalah apa yang ingin mereka selesaikan daripada melompat ke ruang solusi.)

Bukankah GPU akan lebih siap untuk menangani beban rendering? Untuk itulah tepatnya dibuat.

Setuju, kami memprioritaskan apa yang menggunakan CPU dan GPU secara berbeda, membuat fitur terkait grafis menggunakan sumber daya khusus grafis lebih masuk akal. Keuntungan CPU bukanlah kehilangan 1: 1 GPU, dan sebaliknya. Sebagian besar diperdebatkan pada titik ini (hingga bug di Chromium ditambal) tetapi agak relevan karena solusi saat ini masih menggunakan CPU (meskipun dengan bobot yang jauh lebih sedikit).

Saya pikir orang harus berhenti menggunakan teknologi web di desktop, karena memerlukan pengiriman browser yang lengkap dengan setiap program.
Belum lagi, jika Anda memiliki beberapa program tersebut, Anda memiliki binari yang sama yang digandakan di semua tempat.

Kita harus kembali ke logam biasa.

PS: JScript seharusnya sudah dibuang 10 tahun yang lalu, seperti Obj-C seharusnya, jika Apple tidak menghidupkannya kembali.
PPS: ^^^^ ini adalah kata-kata kasar.

PPS: ^^^^ ini adalah kata-kata kasar.

@ bit2shift Memang benar, dan karena itu ia tidak termasuk dalam utas komentar tentang bug yang sangat spesifik. Tolong jangan gunakan komentar masalah GitHub untuk kata-kata kasar.

@ bit2shift - Meskipun saya setuju dengan beberapa bagian (seperti fakta bahwa aplikasi berbasis browser mungkin tidak akan terasa cukup "asli" dibandingkan dengan aplikasi asli yang sebenarnya), seberapa rendah tingkat "logam kosong"? Kode mesin? Bahasa campuran? C? C ++? C #? Akan selalu ada beberapa lapisan abstraksi, terlepas dari tumpukan teknologi Anda.

Belum lagi, jika Anda memiliki beberapa program tersebut, Anda memiliki binari yang sama yang digandakan di semua tempat.

Ini sama dengan aplikasi C # yang menggunakan paket NuGet. Semua assemble bersifat lokal untuk aplikasi. .NET Core bahkan mendistribusikan sebagian besar kerangka kerja sebagai paket NuGet.

karena memerlukan pengiriman browser yang lengkap dengan setiap program.

Secara teknis, Anda dapat menggunakan mesin Edge, yang akan menghindari keharusan menginstal runtime browser terpisah. Internet Explorer melakukan hal serupa hampir 20 tahun yang lalu dengan Aplikasi HTML . Contoh lain adalah React Native, yang menggunakan mesin JS asli OS jika tersedia. Untuk aplikasi berbasis JavaScript, sesuatu seperti React Native for Windows mungkin adalah masa depan daripada teknologi web, karena terasa lebih asli karena menggunakan widget UI asli.

@ Daniel

(...) seberapa rendah level "bare metal" itu? Kode mesin? Bahasa campuran? C? C ++? C #?

Bahasa apa pun yang dapat dikompilasi ke kode mesin (hanya source -> ELF/PE hitungan) dianggap "logam kosong" dalam konteks ini, jadi lapisan abstraksi tidak menjadi masalah di sini.

Internet Explorer melakukan hal serupa hampir 20 tahun yang lalu dengan Aplikasi HTML.

"Sesuatu yang mirip" seperti memiliki mshta.exe gunakan mshtml.dll yang berada di system32 sejak tahun 90-an.

Contoh lain adalah React Native, yang menggunakan mesin JS asli OS jika tersedia. Untuk aplikasi berbasis JavaScript, sesuatu seperti React Native for Windows mungkin adalah masa depan daripada teknologi web, karena terasa lebih asli karena menggunakan widget UI asli.

Jika performa tinggi diinginkan dalam aplikasi JS desktop, maka seseorang dengan cukup waktu harus menulis frontend untuk LLVM.
Anda akan kehilangan kemampuan untuk menjalankan cuplikan kode yang sewenang-wenang, tetapi itu akan menjadi keuntungan dari sudut pandang keamanan.

/benang

Bisakah Anda tidak menggagalkan utas ini? Ini adalah masalah tentang masalah kinerja tertentu dengan kursor yang berkedip dan jelas bukan tempat untuk membahas manfaat umum dari mengembangkan aplikasi desktop berbasis JS.

Anda hanya mengirim spam ke kotak surat orang-orang yang tidak tertarik dengan kata-kata kasar ini.

Bagaimana kalau meletakkan <input type=text> dengan ukuran 2px * 10px di tempat kursornya. Dengan begitu, ia akan menggunakan kursor berkedip asli dari <input> : P <blink></blink> 👍

Juga saya tidak yakin seberapa parah masalah ini, ketika VSCode dalam keadaan idle (saya tidak menulis kode) hampir selalu tidak fokus, fokus pada aplikasi lain yang saya masuki. Dan kursor berhenti berkedip.

dari pengalaman saya, gif tidak begitu bagus. Saya pernah memiliki pemintal pemuatan sebagai gambar gif. dan menggunakannya saat berinteraksi dengan indexeddb. terkadang saya dapat melihat spinner berhenti, bahkan di desktop.

Mendorong perubahan kursor terminal ke master dan rilis / 1.11 (animasi CSS -> setInterval ).

Terima kasih semua telah menyelidiki masalah ini. Investigasi dan saran Anda membantu kami menemukan akar penyebab dan solusi yang mungkin! Kami membandingkan JavaScript setInterval , animasi gif, dan beberapa teknik lainnya, dan kami menetapkan solusi berikut:

• Jika editor.cursorBlinking disetel ke blink atau terminal.integrated.cursorBlinking disetel ke true , logika berkedip sekarang diterapkan di JavaScript. Pengujian kami menunjukkan penggunaan CPU turun menjadi kurang dari 1%.
• Jika editor.cursorBlinking disetel ke smooth , expand atau phase , yang menggunakan fungsi easing CSS, kami akan menghentikan animasi berkedip setelah kursor diam selama 10 detik.

Perbaikan ini sudah ada di build Insider kami dan akan tersedia di build Stabil April yang akan dirilis dalam beberapa hari mendatang. Akan sangat bagus jika beberapa dari Anda dapat memverifikasi hasil tes kami. Jika Anda melihat masalah, buat masalah baru.

@rebornix maksud Anda mengatakan "atau" terminal.integrated.cursorBlinking disetel ke true ? Atau apakah kata "dan" disengaja?

@jedmao terima kasih atas koreksinya, seharusnya or .