Kemarin merupakan hari yang berat buat CPU-ku. Cerita bermula ketika saya mencoba menilik versi terbaru dari browser midori yang artinya saya juga mengunduh dan menginstall webkitgtk versi stabil terbaru. Saat ini midori sudah mencapai versi 0.3.2 yang menyuguhkan beberapa perbaikan pada bagian-bagian antarmuka, mekanisme bookmark dan penanganan sistem input. Silakan lihat ChangeLog midori untuk lebih lengkapnya. Sedangkan webkitgtk saat ini sudah mencapai versi stabil 1.2.7. Kalo mau tahu perubahan apa saja yang terjadi di webkitgtk versi 1.2.7 silakan lihat commit log webkitgtk saja :p .

Proses instalasi webkitgtk dan midori berlangsung tanpa kendala. Setelah ter-install, mulailah saya mencoba kualitas midori. Sebagai pembanding saya menggunakan Konqueror, browser default KDE. Konqueror 4.6.00 menggunakan render engine KWebkitPart versi git ba7d0ff (20110121). Saya memilih konqueror karena sama-sama merupakan browser 'alami' di lingkungan Linux. Kenapa bukan Google Chrome? Sekali lagi saya hanya ingin membandingkan browser-browser alami Linux. Google Chrome saya anggap tidak alami karena meskipun berbasis Linux (ChromeOS) tetapi pengembangannya tidak terintegrasi dengan Lingkungan Desktop dan sistem-sistem di belakangnya. Berbeda dengan Midori yang sudah diadopsi secara resmi oleh XFCE atau Konqueror yang de facto adalah cikal bakal webkit dan sudah ada di dalam KDE sejak kemunculannya pertama kali.

Untuk keperluan tes ini, saya menggunakan mesin dengan spesifikasi berikut ini:

• Prosesor: AMD Phenom(tm) X4 B50 3.1 GHz (AMD Phenom X2 with EC enabled, 4 cores)
• RAM: 1.5 GB
• VGA: ATI Technologies Inc. 760G (Radeon 3000)
• OS: Slackware64-current, Linux 2.6.35.11 x86_64
• DE: KDE 4.6.00

Tes pertama tentu saja adalah ACID3 Test. Sebagai pembanding tambahan saya sertakan juga hasil ACID3 Test dari Mozilla Firefox 4.0b11.

Midori 0.3.2

Konqueror 4.6.00

Mozilla Firefox 4.0b11

Midori dan Konqueror dapat menyelesaikan Tes ACID3 100%, sedangkan Mozilla Firefox hanya mencapai 97%. Terlihat pada gambar terdapat beberapa kesalahan kalkulasi oleh Mozilla Firefox. Ternyata mesin webkit masih yang terbaik dalam mengolah javascript.

Tes kedua adalah olah HTML5. Saya menggunakan website Twitter dengan antarmuka barunya yang sudah menggunakan HTML5 sebagai alat tes. Twitter dengan antarmuka HTML5 dapat menyimpan data-data pengguna secara lokal sehingga pengguna tidak perlu memuat ulang aplikasinya tiap kali ada perubahan data di server. Beda antara Midori dan Konqueror baru terlihat di sini. Kestabilan Konqueror amat sangat unggul jika dibandingkan Midori.

Midori 0.3.2

Konqueror 4.6.00

Dapat kita lihat, bahwa Konqueror memperoleh keuntungan dari KIO untuk memproses seluruh data-data HTML5 berikut Javascript yang ada di dalamnya. Metode pemecahan proses dengan KIO sangatlah menguntungkan aplikasi yang menggunakannya. KIO dapat menurunkan tingkat penggunaan sumberdaya sistem dengan drastis. Hampir tidak ada perubahan drastis dari CPU tiap kali Twitter saya menambah data. Hal ini karena tiap blok data di memoru ditangani oleh proses KIO yang berbeda dan dijalankan secara simultan. Hasilnya antarmuka hanya mengkonsumsi sedikit sekali sumberdaya sistem dan antarmuka Konqueror tidak sampai terganggu aktivitasnya.

Sedangkan Midori amat sangat menderita dengan banjir data dari aplikasi Twitter. Tiap kali ada perubahan data dari Twitter di dalam Midori, CPU dan Harddisk langsung bereaksi secara ekstrim. Saya mendengar bunyi kipas pendingin CPU langsung meninggi tiap kali Twitter saya menambah data. Itu baru menambah data (ada twit baru), belum lagi ditambah dengan beratnya gerakan pointer mouse di atas kanvas Twitter. Itu baru menggerakkan mouse. Saat saya melakukan twitting, penggunaan CPU mendadak menjadi tinggi sekali dan gerakan mouse serta kursor teks menjadi terhenti. Refresh kursor di jendela teks twitter menjadi lama dan susah untuk dipindahkan ke kiri atau ke kanan.

Akhir kata, sebagai sebuah browser Midori masih memiliki kekurangan utamanya dari kestabilan render engine webkit-nya. Jelasnya ini bukan masalah langsung untuk pengembang Midori karena menyangkut webkit. Mungkin pengembang Midori perlu memikirkan sebuah cara untuk memecah-mecah proses render secara lebih efisien. Toh pustaka webkit juga sudah mendukung pustaka gthread dan pthread. Jika saya lihat Midori masih menjalankan proses-proses render secara tunggal. Tapi ini hanya sekedar kritikan dari orang yang gak ngerti programming lho. Jadi tingkat validitasnya bisa dikatakan mendekati nol :) .

Selamat mencoba Midori.