Angka Konkret dalam Diskusi Latensi Input Wayland vs. X11

 (mort.coffee)
2 poin oleh GN⁺ 2025-01-27 | 1 komentar | Bagikan ke WhatsApp
  • Membandingkan Wayland dan X11 dengan merekam latensi input kursor pada lingkungan Fedora Workstation 41·GNOME 47 menggunakan slow motion 240 FPS
  • Mencatat delay frame sebanyak 16 kali untuk Wayland dan 16 kali untuk X11, dengan menghitung dari frame saat mouse mulai bergerak hingga frame saat kursor terlihat di posisi baru
  • GNOME X11 terukur rata-rata 4 frame·16,7 ms·2,4 refresh layar, sedangkan GNOME Wayland terukur rata-rata 5,5625 frame·23,2 ms·3,3 refresh layar
  • Pada sistem tersebut, Wayland menunjukkan latensi kursor sekitar 6,5 ms lebih tinggi secara rata-rata dibanding X11, dan selisihnya hampir setara 1 kali refresh layar
  • Hasil ini hanya menunjukkan perbedaan latensi kursor pada kombinasi GNOME/AMD, dan bukan bukti bahwa latensi input Wayland lebih tinggi pada game atau aplikasi grafis umum

Mengapa diukur

  • Seorang pengguna Linux melakukan eksperimen untuk mendapatkan angka konkret alih-alih rasa subjektif, dipicu oleh tulisan Wayland Cursor Lag: Just give me a break already... yang membahas keluhan latensi input Wayland
  • Ia secara umum puas menggunakan Wayland, tetapi kesan bahwa Wayland memiliki latensi kursor lebih besar dibanding X11 menjadi titik awal eksperimen
  • Kamera ponsel 90 FPS pada tulisan sebelumnya dianggap tidak cukup untuk menilai selisih setingkat satu refresh layar, sehingga digunakan mode perekaman 240 FPS

Metode pengukuran

  • Dengan kamera ponsel, layar, meja, kursor mouse, mouse, dan tangan direkam bersama sambil mouse berulang kali disentil dengan jari
  • Setelah merekam 16 kali pada sesi GNOME Wayland, pengguna login ke sesi GNOME X11 dan merekam 16 kali dengan metode yang sama
  • Video yang direkam dikonversi menjadi frame JPEG dengan perintah ffmpeg -i <input file> %04d.jpg
  • Delay frame dihitung dengan kriteria berikut
    • Perhitungan dimulai dari frame pertama tempat mouse terlihat bergerak
    • Dihitung hingga frame pertama tempat kursor terlihat jelas bergerak di posisi baru
    • Frame awal dan frame akhir sama-sama disertakan
    • Misalnya, jika mouse bergerak pada frame 1045 dan kursor bergerak pada frame 1047, itu dicatat sebagai delay 3 frame

Lingkungan pengujian

  • Hardware dan software eksperimen adalah sebagai berikut
    • Distro: Fedora Workstation 41
    • Versi GNOME: 47
    • CPU: AMD Ryzen 9 5950X
    • GPU: AMD Radeon RX 7900XT
    • Monitor: Gigabyte M32U, 4K IPS, 144,99 Hz, tanpa scaling DPI
    • Mouse: Logitech G502 Lightspeed
    • Kamera: iPhone 15 Pro, slow motion 240 FPS

Keterbatasan pengukuran

  • Bahkan 240 FPS pun menghasilkan kurang dari 2 frame kamera per refresh layar pada layar 144 Hz, sehingga muncul variasi acak
  • Karena piksel tidak berubah seketika, ada frame ambigu ketika kursor mulai tampak sangat samar di posisi baru
  • Meski kursor belum sepenuhnya terang, jika terlihat jelas di posisi baru, itu dihitung sebagai kursor telah bergerak
  • Video iPhone memuat beberapa frame duplikat, dan penyebabnya tidak diketahui
    • Frame duplikat dianggap sebagai waktu satu frame yang telah berlalu dan dihitung seperti frame normal
  • Faktor-faktor ini menimbulkan ketidakpastian pada hasil, tetapi diperkirakan berlaku sama pada Wayland dan X11 serta akan teraverasi jika datanya cukup
  • Kompositor Wayland selain GNOME dan driver GPU selain AMD tidak diuji, sehingga hasilnya bisa berbeda pada kombinasi lain

Hasil pengukuran

  • Nilai 16 pengukuran GNOME X11 adalah 5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4 frame
    • Rata-rata: 4 frame
    • Waktu latensi: 16,7 ms
    • Refresh layar: 2,4 kali
  • Nilai 16 pengukuran GNOME Wayland adalah 6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6 frame
    • Rata-rata: 5,5625 frame
    • Waktu latensi: 23,2 ms
    • Refresh layar: 3,3 kali
  • Pada sistem ini, Wayland menunjukkan latensi kursor rata-rata sekitar 6,5 ms lebih tinggi dibanding X11
  • Penulis tidak memiliki keahlian untuk menganalisis dengan benar apakah ini signifikan secara statistik, tetapi dari nilai pengukuran tampaknya ada perbedaan yang jelas dan konsisten
  • Selisihnya hampir setara 1 kali refresh layar, dan tidak diketahui apakah itu kebetulan

Kesimpulan dan cakupan interpretasi

  • Eksperimen ini menunjukkan bahwa pada hardware tertentu ada perbedaan latensi input antara X11 dan Wayland, dan besarnya bisa cukup terasa bagi sebagian pengguna
  • Untuk memahami cakupan dan besarnya masalah dengan jelas, diperlukan pengujian tambahan pada hardware dan refresh rate layar yang lebih beragam
  • Besar selisih dapat bervariasi tergantung faktor seperti kompositor yang digunakan dan refresh rate layar
  • Eksperimen tambahan kemungkinan besar tidak akan dilakukan sendiri karena memakan banyak waktu
  • Pengujian ini tidak menunjukkan bahwa Wayland secara umum memiliki latensi input lebih tinggi dibanding X11
    • Khususnya, ini bukan bukti bahwa latensi input Wayland lebih tinggi pada game
    • Ada kemungkinan latensi tambahan tersebut khusus untuk kursor
    • Kursor dipahami diproses dengan cara yang sangat berbeda dari aplikasi grafis umum
    • Apakah Wayland menunjukkan latensi input lebih tinggi dibanding X11 pada game memerlukan pengujian terpisah

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-27
Komentar Hacker News

  • Pendekatan yang bagus. Rasanya orang terlalu sering menebak-nebak hal yang sebenarnya bisa lebih diverifikasi secara eksperimental. Sejak mempelajari metode ilmiah, saya selalu tertarik pada gagasan “mari rancang eksperimennya”
    Saya tidak tahu kenapa Wayland menambahkan latensi ekstra, tetapi sebagai orang yang berada di komunitas komputer pada masa X11 pertama kali muncul, saya bisa bilang bahwa sejak awal keluhan soal latensi tampilan tidak pernah berhenti. Baik respons kursor maupun scroll xterm, sama saja
    Saat “workstation” muncul, ada juga yang memiliki hardware tampilan terpisah khusus untuk mouse, sebagai perangkat untuk mengurangi latensi merender mouse di dalam frame. Ada juga paten XOR yang terkenal buruk itu: https://patents.google.com/patent/US4197590
    Berkat keluhan semacam ini, jalur kode dari input keyboard/mouse sampai tercermin di layar terus ditinjau agar bisa dibuat “lebih cepat, dengan latensi lebih rendah”. Wayland relatif “baru” dibanding X11 sehingga belum diuji selama itu, tetapi saya berharap orang-orang akan terus memperbaikinya

    • Perangkat display, biasanya sebagian dari GPU, masih memiliki hardware tampilan eksplisit khusus untuk mouse, yang kini hadir sebagai cursor plane. Setelah itu muncul juga overlay plane, generalisasi dari konsep tersebut
      Plane dapat diperbarui atau dipindahkan posisinya tanpa menggambar ulang sisa layar. Gambar layar biasa berada di plane dasar, sedangkan pergerakan kursor lebih mirip melakukan commit posisi plane baru
      Latensi input tambahan yang ditambahkan GNOME Mutter, server Wayland yang digunakan di sini, kemungkinan besar adalah masalah strategi timing sampling input dan commit. Tiap server punya strategi dan prioritas berbeda, sehingga muncul kelebihan dan kekurangan
      Wayland adalah protokol, jadi tidak terlibat dalam proses penentuan posisi kursor umum. Karena itu, masalah ini sepenuhnya berada di ranah implementasi internal dan optimisasi display server. Di level protokol, yang terjadi hanya klien dapat menetapkan gambar kursor dan klien diberi tahu posisi kursor
    • Dulu XFree86 dan Xorg memperbarui pointer secara langsung di dalam handler SIGIO. Namun itu sudah cerita sangat lama, dan sekarang saya tidak berharap Wayland dan Xorg akan sangat berbeda di area ini
      Seingat saya, situasi mulai memburuk ketika glamour muncul di Xorg. Saat jalur rendering kursor tidak lagi aman dijalankan dari signal handler—dan kalau berbasis OpenGL, tentu saja memang begitu—latensinya makin buruk
      Dulu, meski mesin Linux sedang thrashing, pointer mouse tetap responsif, dan itu menjadi indikator andal untuk menilai apakah kernel benar-benar hang atau tidak. Jika pointer tidak merespons cukup cepat, biasanya itu kasus di host IDE/PATA yang perlu mengaktifkan unmask irq dengan hdparm. Pointer yang tidak responsif di XFree86 adalah sinyal yang sangat berguna bahwa ada sesuatu yang salah atau konfigurasi keliru; saya merindukan masa itu
    • Berapa umur Wayland sekarang? Dengan kecepatan begini, rasanya ia akan membaca “mimpi musim semi” dari liang kubur
      Saya paham ini keluhan terhadap software gratis, tetapi sudah terlalu lama kita dipaksa beralih ke sesuatu yang lebih buruk. Adopsi Wayland seharusnya dilakukan atas dasar bahwa ia nyaris secara universal lebih unggul untuk semua kebutuhan input dan display
      Intel, AMD, Nvidia, para produsen Arm harus habis-habisan membentuk konsorsium demi desktop Linux yang layak pakai. Pemerintah juga demikian. Karena desktop Linux yang aman sebenarnya mungkin, dan itu adalah jalur tercepat untuk memamerkan kemampuan CPU, 3D, serta hardware vektor/komputasi kelas atas
      Wayland muncul pada masa Windows sedang mencoba merusak dirinya sendiri dengan UI tile yang mengerikan, dan Apple keras kepala menolak tambahan kapitalisasi pasar yang bisa didapat jika merilis macOS untuk x86 umum; pada akhirnya ia justru makin memperpanjang keterlambatan desktop Linux
    • Pernyataan bahwa “ada hardware tampilan eksplisit khusus untuk mouse sehingga latensi berkurang” masih berlaku sampai sekarang. Kursor mouse dirender sebagai sprite/overlay yang independen dari swapchain compositor jendela. Kalau tidak, terutama pada 60Hz, latensinya akan sangat terlihat
      Yang membutuhkan trik adalah saat menyeret jendela atau ikon; pada saat itu latensi swapchain mulai terlihat. Sebagian compositor jendela menganggap latensi tidak terlalu tampak berkat refresh rate tinggi dan tidak lagi memedulikannya, misalnya macOS; sementara Windows tampaknya beralih ke kursor mouse software saat drag berlangsung
    • GNOME memiliki dukungan unredirection, jadi sulit mengatakan bahwa tes ini berlaku untuk performa game sebenarnya
      Aplikasi fullscreen seharusnya melewati jalur cepat, baik melalui compositor maupun dengan mem-bypass-nya

  • Jika menggunakan ffmpeg untuk analisis per-frame seperti ini, Anda bisa mendapatkan waktu tampil tiap frame video dengan ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png. Ini lebih akurat daripada sekadar mengekspor frame dan menghitung timestamp
    Di browser web, hal serupa bisa dilakukan dengan memutar video lalu memakai requestVideoFrameCallback(). Namun jika komputer tidak mampu mendekode semua frame dengan cukup cepat, mungkin perlu menurunkan .playbackRate
    Fakta bahwa pada layar 144Hz Wayland rata-rata sekitar 6,5ms lebih lambat daripada X11, dan selisih itu hampir sama dengan satu kali refresh layar, mungkin bukan kebetulan. Jika latensinya hampir 1/144 detik, pada monitor 60Hz biasa bisa menjadi 1/60 detik. Sulit disadari secara sadar tanpa latihan, tetapi kebanyakan orang bisa “merasakannya” meski tidak dapat menjelaskannya

    • Kalau menebak, angka “sebenarnya” tampaknya lebih dekat ke 2,5 frame dan 3,5 frame. Karena fase acak antara saat mouse disentuh dan refresh layar, rata-rata ada setengah frame, lalu ditambah 2 atau 3 frame sampai gerakan kursor muncul. Jika outlier rendah di tiap kelompok dikeluarkan, nilainya cukup mendekati itu
      Tentu bagi banyak pengguna, polling rate mouse 125Hz juga menjadi faktor pengganggu, tetapi dalam kasus ini digunakan mouse 1KHz
      Selisih 7ms tidak buruk, tetapi selisih 16,6ms mulai terasa cukup besar. Secara pribadi, menurut saya komputer seharusnya berupaya menargetkan latensi 1,6 frame: setengah frame fase acak, satu frame, dan sedikit waktu pemrosesan
    • Terminal latensi rendah memberi peningkatan yang sangat terasa bahkan untuk pekerjaan seperti mengetik sederhana
    • Hampir pasti ada tambahan satu frame buffering antara gerakan mouse dan layar. Sinkronisasi vertikal bisa menyebabkannya, tetapi sinkronisasi vertikal semestinya tetap bisa dilakukan hanya dengan double buffering

  • Hasilnya akan berbeda tergantung compositor, GPU, dan pengaturan. Di X11, implementasi server X yang dipakai sistem desktop Linux pada praktiknya hanya satu, jadi perbedaan seperti ini lebih kecil
    Masih mungkin ada masalah di banyak kombinasi compositor/GPU yang belum mendapatkan bidang kursor perangkat keras, dan jika demikian, perbedaan latensi seperti ini sangat mungkin terjadi

  • Baru tahu hari ini bahwa Wayland ternyata sudah berumur 16 tahun. Dalam beberapa tahun lagi umurnya akan sama dengan umur X ketika Wayland muncul, tetapi tampaknya masih dianggap biasa saja atau kalah dari X

    • Rilis pertama X adalah Juni 1984 dan Wayland pertama kali muncul pada 2008, jadi agar Wayland mencapai umur yang sama, harus sampai 2032. Ketika orang mengeluh bahwa Wayland biasa saja atau “tidak sebagus X”, biasanya maksudnya adalah “Wayland tidak mendukung $very_specific_feature” atau “sedih karena driver proprietary dari produsen kartu grafis saya belum cukup diuji di Wayland”
      Sekitar 99,999% keluhan semacam itu datang dari orang-orang yang 1) tidak mengerjakannya sendiri, 2) tidak punya minat atau kemampuan untuk mengerjakannya, dan 3) tidak memahami atau tidak mau mengakui bahwa pengembang Wayland dan X sebagian besar adalah orang yang sama, dan mereka tidak lagi ingin mengerjakan X11
      Saya tidak punya kepentingan khusus dalam perdebatan ini, tetapi sudah lelah melihat orang mengeluhkan Wayland sambil memakai perangkat lunak yang diberikan gratis oleh orang lain. Kalau keluhan tentang Wayland sebanyak itu, seharusnya sekarang mereka sudah bisa berkumpul untuk memelihara dan meningkatkan X, lalu jika keluhan dan teorinya benar, meninggalkan Wayland di belakang
      Anehnya, X itu open source dan bisa di-fork sesuka hati, dan meski ada contoh X.org yang lahir dari XFree86, para pendukungnya hanya membiarkannya berdebu dan tidak melakukan apa pun untuk pemeliharaan
      Saya akan cukup tertarik melihat hasil berupa “Wayland tidak sebagus X, jadi kami membuat fork X modern yang bisa dipakai siapa saja”
    • Tidak, bukan begitu. X berasal dari 1984: https://www.talisman.org/x-debut.shtml
      Artinya, Wayland baru sekitar 66% dari umur X saat Wayland muncul, dan untuk mencapai umur yang sama, masih perlu tambahan 50% dari usia Wayland saat ini
    • Jika X berumur 40 tahun dan Wayland 16 tahun, selisihnya 24 tahun. Jadi compositor Wayland masih punya 8 tahun untuk mematangkan masalah-masalahnya
      Saat ini saya memakai Wayland di Plasma 6 dan berfungsi cukup baik, tetapi saya tidak punya kebutuhan khusus, jadi misalnya saya tidak tahu seberapa baik dukungan untuk screen reader
    • Dilihat dari sisi lain, angka ini juga berarti bahwa dalam beberapa tahun lagi sudah waktunya penerus Wayland muncul. Alasannya bisa sama seperti motivasi Wayland, yaitu kurangnya orang yang mau memelihara perangkat lunak legacy
      Pada titik itu, saya memperkirakan stack frontend browser akan sepenuhnya memakan desktop. Lagi pula, memang tidak banyak aplikasi desktop baru yang muncul di Linux
    • Wayland muncul pada masa yang sama dengan compositor Windows Vista. Jika bermurah hati dan menganggap versi berikutnya, Windows 7, memiliki compositor yang “bagus dan stabil”, maka Wayland tertinggal 13 tahun dari Windows

  • Upaya menulis ulang solusi yang sudah berfungsi dengan alasan “lebih modern, lebih mudah dipelihara, dan siap masa depan” biasanya memang tidak berakhir seperti itu, jadi tidak mengherankan. Umumnya menjadi lebih lambat, latensi meningkat, dan hanya ditopang oleh perangkat keras yang lebih cepat; bukan karena perangkat lunaknya menjadi lebih cepat
    Rasanya setiap 20 tahun, generasi baru menjadi lebih lemah karena manja bergantung pada abstraksi yang dibuat generasi sebelumnya dengan kerja keras. Setelah kira-kira tiga generasi pengembang perangkat lunak, yang tersisa hanya pemanggil library/framework, dan hampir tidak ada orang yang benar-benar memahami performa dan optimisasi

    • Pengalaman saya berbeda. Saat memutakhirkan beberapa komputer ke KDE 6 dan beralih ke Wayland, responsivitas dan kelincahan sistem secara keseluruhan terasa meningkat jelas
      Wayland memang masih kekurangan beberapa fitur dibanding X11, tetapi karena keunggulan lainnya, saya bersedia berkompromi soal itu
    • Komputer lama memang memiliki latensi lebih rendah, tetapi sebaliknya di banyak sistem operasi, jika satu aplikasi mati, seluruh OS menjadi tidak responsif sehingga seluruh sistem harus di-reboot

  • Banyak compositor Wayland punya masalah besar dengan keyboard, mouse, dan perangkat input lain. Ini karena spesifikasi dan implementasi referensi Wayland memutuskan untuk tidak mendukung hal-hal itu. Akibatnya setiap compositor Wayland memilih solusi yang berbeda-beda
    Pilihan umum adalah libei dan libinput, tetapi input mouse/keyboard “lanjutan” sering kali sama sekali tidak didukung. weston adalah salah satu contohnya. Kita sama sekali tidak bisa tahu apakah perangkat lunak Linux tertentu akan berjalan di lingkungan Wayland tertentu, dan fragmentasinya parah
    Di X, ada referensi X11 yang kuat yang benar-benar mengimplementasikan semuanya, sehingga jika sesuatu berjalan di satu tempat, kita bisa yakin itu juga berjalan di tempat lain
    Bahkan setelah 12 tahun, belum ada satu pun compositor Wayland yang mendukung screen reader untuk tunanetra. Ini masih setingkat mainan

    • Saya dengar dukungan kalibrasi warna juga hilang. Setelah membaca, sepertinya bahkan tidak ada cara untuk mengontrol atau mengetahui kalibrasi apa yang diterapkan saat aplikasi kalibrasi mencoba melakukan pengukuran. Selain itu, dekorasi jendela sisi klien juga masih ada, sehingga kesempatan untuk memperbaiki lubang keamanan lama pun dilepas
      Jadi tidak bagus untuk gim, tidak bagus untuk pekerjaan grafis profesional, dan tidak bagus untuk orang dengan penglihatan kurang baik. Pada akhirnya, ini berarti umumnya tidak bagus untuk pengguna yang sedikit saja berbeda dari para pembuatnya
      Namun kalau beruntung, mungkin ini mengurangi screen tearing yang belum pernah saya rasakan sendiri
    • Setelah pindah dari macOS ke Windows, akhirnya saya menetap di Windows, dan waktu pengembangan luang saya saya pakai untuk meningkatkan pengalaman power user/pengembang di ekosistem tiling window manager di Windows: https://github.com/LGUG2Z/awesome-komorebi
      Salah satu hasil keren dari sini adalah melihat orang menambahkan alur kerja aksesibilitas di atas ekosistem ini. Ada orang yang mengoperasikan seluruh desktop melalui tiling window manager dengan kontrol suara: https://youtu.be/fiPJLmhnnXM
    • Pernyataan “sama sekali tidak mendukung input mouse/keyboard lanjutan” sepertinya menyalahkan pihak yang keliru. Yang perlu dilihat adalah perusahaan yang membuat periferal semacam itu tetapi tidak menyediakan driver Linux
    • Apa yang kurang saat memakai Orca di Wayland GNOME?

  • Saat GPU menerima beban besar, misalnya ketika menjalankan inferensi Stable Diffusion, muncul lonjakan latensi yang besar. Memang belum pernah melakukan uji A/B dengan X11, tetapi dulu rasanya tidak pernah mengalami ini
    Tambahan latensi sebesar satu frame saja sudah kurang bagus, tetapi lonjakan latensi yang sesekali muncul itu benar-benar menjengkelkan

    • Terutama jika terjadi thrashing antara VRAM dan memori sistem, hal ini masih bisa terjadi. Meski begitu, saya penasaran apakah sudah mencoba menurunkan prioritas proses Stable Diffusion

  • Latensi input kursor adalah gangguan yang terus menggerogoti kepuasan terhadap aplikasi atau sistem operasi
    Latensi kursor teks di IDE? Tidak bisa diterima
    Latensi kursor teks di shell? Tidak bisa diterima
    Latensi kursor mouse GUI? Tidak bisa diterima
    Semuanya adalah alasan langsung untuk gugur

    • Ini salah satu area yang selalu menjadi keunggulan macOS, bahkan sejak era Mac OS klasik
      Bahkan System 1 yang berjalan lebih dari 40 tahun lalu di perangkat keras yang hampir tak terbayangkan lemahnya menempatkan responsivitas kursor sebagai prioritas tertinggi, mengungguli semua pesaing. Fondasi OS dan UI saat ini sudah 100% berbeda, tetapi prioritas itu tetap dipertahankan
    • Agak mengejutkan bahwa ini bisa seburuk ini. Apalagi di Linux. Bukankah pergerakan mouse seharusnya diprioritaskan di atas segalanya? Bahkan penyorotan objek yang sedang diarahkan mouse pun tidak boleh membuat kursor mouse itu sendiri melambat
      Baru-baru ini saya mengalami perlambatan mouse yang parah pada kombinasi KDE/Plasma 6 X11 dan NVidia. Saya menyadari perlambatannya sangat terasa terutama di atas tab browser
      Untuk orang lain yang mengalami masalah sama, solusinya adalah mematikan OpenGL flipping. Saya sama sekali tidak tahu apa fungsi OpenGL flipping, tetapi setelah dimatikan di nvidia-settings dan /etc/X11/xorg.conf, masalahnya teratasi
      Saya ingin ada yang menjelaskan mengapa demikian, atau mengapa ini bukan nilai default

  • Kerja yang bagus. Sepertinya layak mengulang eksperimen dengan monitor disetel ke refresh rate yang sangat rendah, misalnya 30Hz
    Jika Wayland selalu satu frame lebih lambat daripada X11, itu akan jauh lebih mudah diamati

  • Saya punya keluhan pribadi yang sedikit berbeda. Saat pertama mulai memakai Linux, desktop menggunakan compositing berbasis software. Mungkin CPU menggambar UI ke RAM lalu melakukan blit ke framebuffer GPU, dan saya kira itu memang cara yang sudah lama dipakai
    Dengan compositor, termasuk X11 composite, lalu renderer GPU menjadi populer, latensinya menjadi mengerikan dan secara harfiah mencapai ratusan ms. Ini terasa aneh karena saat tumbuh dengan memainkan game DOS, masalah seperti ini tidak ada
    Seiring waktu memang membaik, tetapi saya tidak yakin apakah kita sudah kembali ke masa keemasan rendering CPU