- Fondasi rendering GTK ditata ulang menjadi ngl untuk GL dan vulkan untuk Vulkan, dengan kedua renderer memakai struktur terpadu yang dibangun dari sumber yang sama
- Implementasi bersama mengabstraksikan perbedaan antara GL 3.3+ dan GLES 3.0+ berdasarkan alur API Vulkan, sehingga dapat berbagi infrastruktur rendering seperti traversal scene graph dan cache
- Renderer baru untuk saat ini lebih memprioritaskan ketepatan dan kemudahan pemeliharaan daripada kecepatan, sambil meningkatkan anti-aliasing, penskalaan fraksional, titik henti warna gradien tanpa batas, dan dukungan dmabuf
- Pengembang aplikasi perlu memeriksa tidak adanya dukungan node glshader, perubahan penanganan posisi fraksional, serta kemungkinan masalah driver; bahkan jika terlihat seperti masalah driver, sebaiknya tetap dilaporkan ke GTK
- Dalam snapshot GTK 4.13.6, ngl menjadi default baru, tetapi masih dalam tahap uji coba, dan jika ada masalah besar dapat dikembalikan ke renderer gl lama di GTK 4.14
Renderer terpadu untuk GL dan Vulkan
- GTK menambahkan renderer baru ngl untuk GL dan vulkan untuk Vulkan
- Kedua renderer dibangun dari sumber yang sama sehingga disebut renderer terpadu
- Model implementasinya mengikuti API Vulkan, dengan abstraksi untuk menangani perbedaan GL 3.3+ dan GLES 3.0+
- Berkat struktur ini, pekerjaan dasar yang sebelumnya dipelihara terpisah untuk tiap renderer kini bisa dibagi bersama
- Traversal scene graph
- Pemeliharaan transformasi dan status lainnya
- Cache tekstur dan glif
- Pekerjaan menjaga kedua renderer tetap sinkron dan mutakhir
Syarat saat diperluas ke Metal dan DirectX
- Pendekatan yang sama berpotensi diperluas ke renderer berbasis Metal di macOS atau renderer berbasis DirectX di Windows
- Vulkan dan GL diuntungkan karena pada dasarnya berbagi bahasa shader yang sama, yaitu GLSL
- Kondisi yang sama tidak berlaku untuk Metal atau DirectX, sehingga perlu menulis shader ganda atau memakai alat konversi seperti SPIRV-Cross
- Kontributor yang tertarik dengan pekerjaan ini sangat disambut
Cara implementasi dan ubershader
- Renderer GL lama menggunakan shader sederhana untuk tiap tipe rendernode, dan pada konten yang kompleks sering bergantung pada rendering offscreen
- Renderer terpadu juga memiliki shader per-node yang lebih kuat, tetapi selain itu juga menggunakan shader kompleks yang menafsirkan data buffer sebagai pengganti offscreen
- Dalam pemrograman game, pendekatan ini disebut ubershader
- Implementasi baru ini belum seoptimal renderer GL lama, tetapi memprioritaskan ketepatan dan kemudahan pemeliharaan sehingga dapat menangani lebih banyak variasi pohon rendernode dengan benar
Kualitas rendering dan fitur baru
-
Anti-aliasing
- Renderer GL lama bisa kehilangan detail kecil yang cukup sempit untuk berada di antara batas satu baris piksel
- Masalah ini juga dapat memengaruhi garis bawah seperti mnemonic
- Renderer terpadu lebih baik dalam mempertahankan detail kecil dan juga mengurangi efek tangga pada tepi primitif
-
Penskalaan fraksional
- Anti-aliasing menjadi dasar untuk menangani skala fraksional dengan benar
- Saat jendela 1200×800 diskalakan ke 125%, renderer terpadu menggunakan framebuffer 1500×1000
- Ini memproses jauh lebih sedikit piksel dan menghasilkan gambar yang lebih tajam dibanding membiarkan compositor menurunkan skala gambar 2400×1600
-
Gradien arbitrer
- Renderer GL lama hanya dapat menangani maksimal 6 titik henti warna pada gradien linear, radial, dan kerucut
- Renderer terpadu mengizinkan jumlah titik henti warna tanpa batas
- Anti-aliasing juga diterapkan pada gradien untuk membuat garis yang halus pada batas yang tajam
-
dmabuf
- GTK mengerjakan dukungan dmabuf dan offloading grafis sejak musim gugur lalu
- Renderer baru mendukung ini, dan memperluas API render_texture agar dapat membuat dmabuf saat diminta membuat tekstur
- Saat ini perluasan ini hanya berlaku untuk renderer Vulkan
Hal yang perlu diperiksa pengembang aplikasi
-
Node glshader tidak didukung
- Node glshader berguna untuk demo GTK 4.0, tetapi sangat terikat pada renderer GL lama
- Node tersebut mengasumsikan API GLSL yang diekspos oleh renderer lama
- Renderer baru tidak mendukung node glshader
- Dokumentasi GTK menyarankan untuk memvalidasi sebelum bergantung pada shader, dan jika gagal gunakan shader yang lebih sederhana atau jalur fallback tanpa shader
- Sejak GTK 4.0, fitur seperti node mask dan dukungan tekstur straight-alpha telah ditambahkan, sehingga banyak kasus penggunaan node glshader tidak lagi diperlukan
-
Posisi fraksional
- Renderer GL lama membulatkan posisi, sehingga masalah mungkin tidak terlihat meski posisi fraksional diberikan
- Renderer baru menempatkan objek tepat pada posisi yang ditentukan
- Perbedaan ini dapat menghasilkan hasil yang tidak diinginkan, jadi perlu memastikan nilainya memang seperti yang diharapkan
- Terutama, perhatikan gambar bergaya cairo yang menempatkan garis pada posisi setengah piksel untuk mengisi tepat satu baris piksel
-
Masalah driver
- Renderer baru menggunakan driver grafis dengan cara yang baru dan berbeda, sehingga ada kemungkinan memicu masalah di sisi driver
- Meski masalahnya terlihat seperti isu driver, sebaiknya tetap dilaporkan ke GTK
- Ini membantu memahami seberapa baik kode baru bekerja di berbagai driver dan perangkat keras
Kondisi performa saat ini
- Renderer baru masih belum lebih cepat daripada renderer lama
- Renderer GL lama sangat dioptimalkan untuk kecepatan, memakai shader yang lebih sederhana, dan tidak melakukan perhitungan yang dibutuhkan untuk fitur seperti anti-aliasing
- Tujuan akhirnya adalah membuat renderer baru lebih cepat, tetapi saat ini peningkatan terbesarnya ada pada fitur baru dan ketepatan
- Semua renderer berbasis GPU saat ini sudah cukup cepat untuk merender aplikasi GTK pada 60fps atau 144fps
- Dalam benchmark tidak ilmiah, renderer Vulkan mendekati atau dalam beberapa kasus melampaui renderer GL lama
- Alasan renderer GL baru lebih lambat masih belum terlacak
Perubahan default dan pengecualian
- Dalam snapshot GTK 4.13.6 yang baru dirilis, renderer ngl menjadi default baru
- Perubahan ini adalah uji coba, dan perlu pengujian yang lebih luas di berbagai aplikasi untuk memastikan kesiapan produksi
- Jika muncul masalah besar, GTK 4.14 dapat kembali ke renderer gl lama
- Renderer Vulkan masih belum menjadi default
- Port WebKit GTK4 berfungsi di GL tetapi tidak di Vulkan
- GtkGLArea dan GtkMediaStream saat ini membuat tekstur GL, dan renderer Vulkan belum dapat mengimpornya secara langsung
- Jika masalah-masalah ini terselesaikan dalam waktu dekat, keputusan renderer default akan ditinjau ulang
- Jika menggunakan GTK pada perangkat keras yang sangat tua, renderer GL lama mungkin lebih baik
- Renderer GL lama memiliki persyaratan yang lebih ringan terhadap GPU
- Pemilihan renderer dapat dioverride dengan variabel lingkungan
GSK_RENDERER - Contoh:
GSK_RENDERER=gl
Pekerjaan yang mungkin dilakukan ke depan
- Renderer baru menjadi fondasi untuk mewujudkan fitur-fitur yang sudah lama diinginkan
- Pekerjaan yang mungkin dilakukan ke depan mencakup
- Pemrosesan warna yang benar, termasuk HDR
- Rendering path di GPU
- Kemungkinan termasuk rendering glif
- Rendering di luar thread utama
- Peningkatan performa pada perangkat lama dan kurang bertenaga
- Beberapa poin ini diperkirakan akan menjadi fokus pekerjaan jangka pendek dan menengah
- Fitur tambahan lain juga direncanakan untuk renderer baru, dan pengguna dapat langsung mencobanya serta memberi tahu apakah semuanya berfungsi
1 komentar
Pendapat di Hacker News
Dulu sekali, mungkin sekitar 2010, rasanya ada renderer HTML eksperimental yang menjalankan aplikasi GTK di dalam browser dan menyusun UI dengan HTML+CSS biasa
Waktu itu benar-benar mengejutkan, dan sepertinya itu sebelum Atom, VS Code, Electron, bahkan mungkin NodeJS muncul
Aku tidak tahu apakah renderer itu masih ada
https://docs.gtk.org/gtk4/broadway.html
https://www.phoronix.com/news/GTK4-Broadway-Being-Used
Aku tidak menganggapnya sebagai backend arus utama/resmi, tapi masih ada dan juga sudah di-port ke Gtk4
Karena karakteristik perilakunya lebih dekat ke pendekatan canvas murni yang membuang hampir semua yang disediakan browser dan membangun ulang dari nol
Tolok ukur untuk menilai perilaku yang benar umumnya adalah (a) memakai scrolling browser, (b) memakai rendering teks browser, (c) memperlakukan tautan sebagai elemen sungguhan, dan Broadway gagal di ketiganya
Ia mengimplementasikan ulang scrolling, merender teks di server lalu mengirimkannya sebagai gambar, dan kalau mencoba mengklik tautan, sepertinya benar-benar berhenti
Selain itu input teks juga tampaknya hanya memakai event tombol, sehingga komposisi IME benar-benar rusak, dan navigasi keyboard kemungkinan besar bukan native melainkan dari sisi GTK
Accessibility tree juga tidak bisa disediakan secara bermakna
Untuk demo teknis atau penggunaan pribadi yang siap menerima batasannya masih oke, tetapi tidak cocok untuk distribusi publik dan pada dasarnya lebih mirip jenis RDP/VNC dengan sedikit penggunaan DOM
Perlu diingat juga bahwa semua kode berjalan di server
Pada dasarnya ini men-stream data piksel ke elemen canvas, jadi hampir sama dengan VNC yang diberi web viewer
https://imgur.com/a/2EDZ2Ti
https://github.com/moondev/gtk3-docker
Kebutuhanku adalah menjalankan browser di dalam browser agar bisa berinteraksi dengan mudah dengan layanan Kubernetes clusterip tanpa port forwarding atau proxy
Contoh keren lainnya adalah menjalankan virt-manager, lalu menjalankan VM dengan gtk virt-viewer dan mengendalikannya dari browser
https://github.com/m-bers/docker-virt-manager
Aku berharap GTK tidak mengikuti tren memasukkan widget di title bar
Ada yang bisa di-drag dan ada yang tidak, dan ruang untuk menampilkan nama aplikasi serta nama file juga berkurang
Ini bukan keluhan khusus untuk GTK saja
Fractional scaling yang akurat hingga tingkat piksel, bagus, woohoo!
Kalau sekarang Wayland mendukungnya dengan benar, sepertinya dukungan HiDPI akan tersedia di semua lingkungan desktop Linux utama
Katanya jika jendela 1200×800 diskalakan ke 125%, unified renderer memakai framebuffer 1500×1000 alih-alih membiarkan compositor mengecilkan gambar 2400×1600
Sejauh yang kupahami, karena skala 125%, jendela yang harus digambar sebagai 1500×1000 piksel di layar berarti berukuran 1200×800 dalam piksel aplikasi
Karena OpenGL dan Vulkan merender dengan floating point, maksudnya mungkin cukup menggambar langsung ke buffer yang bisa dirender 1:1 di layar melalui transformasi koordinat
Jika benar begitu, akhirnya ini terlihat sebagai cara yang masuk akal
Apakah ada orang yang benar-benar memahami bagaimana desktop environment bekerja di Linux? Aku sendiri tidak begitu paham
Rasanya hanya makin kompleks dan penuh tempelan
Arsitektur client/server pada akhirnya berlawanan total dengan model pemrosesan grafis yang sangat terintegrasi yang akhirnya kita capai
Alih-alih meninggalkan X11 lebih awal dan memangkas kerugian, baik vendor Unix maupun pihak open source terlalu lama mencoba membuat limun dari satu truk lemon busuk
Itulah sebabnya GUI Linux tertinggal sejauh ini
Apple tidak terikat pada X11 dan menerima model terintegrasi, sehingga bisa mengembangkan GUI Unix dengan cepat, dan menariknya kini mereka bahkan merancang GPU sendiri
Aku penasaran sebesar apa dampak arsitektur Wayland nanti, dan apakah aplikasi khusus GNOME benar-benar akan muncul
Akan bagus kalau ada perender teks ANSI
Supaya saya bisa menjalankan program GTK di dalam xterm saya, dan secara opsional ingin sedikit menambahkan sixel juga
Sidebar, beberapa perilaku pada title bar, dan struktur tampilan detail
Aplikasi Mac, aplikasi Windows “Modern”, dan aplikasi mobile juga mirip
Saya penasaran apakah toolkit UX bisa sepenuhnya deklaratif dan semantik
Pada level tinggi seperti “master/detail view, list view dengan field seperti ini, dan perlu beberapa aksi”, tidak memberikan posisi atau gaya, melainkan otomatis memakai widget sistem yang sesuai
Di atasnya bisa ditambahkan sedikit CSS atau jalan keluar untuk beralih ke widget native
Hampir semua aplikasi yang bukan browser, editor WYSIWYG, atau media viewer tampaknya cocok dengan kerangka ini, dan poin utamanya adalah TUI bisa dibuat dengan mudah dari deskripsi semacam ini
https://github.com/fathyb/carbonyl
https://i.imgur.com/pIQ4K7Q.png
Kalau saja memakai https://wgpu.rs/, DirectX dan Metal bisa didapat gratis :)
Pekerjaan ini kelihatannya benar-benar menarik
Saat membaca bagian antialiasing, saya berpikir apakah signed distance field seperti di game engine juga bisa bekerja dengan baik untuk rendering font pada skala sembarang
Valve pernah menerbitkan paper yang bagus tentang topik ini
Ada banyak teknik keren di kode UI renderer game atau rendering decal yang juga mungkin berguna untuk kode GUI
Saya tidak mengerti mengapa penurunan performa bisa diterima
Saya melakukan sebagian besar pekerjaan di hardware lama, dan kalau bisa fitur-fitur seperti ini ingin saya matikan; bahkan mungkin tidak didukung di GPU saya
Kalau ada penurunan performa yang terasa, gunakan
GSK_RENDERER=glMicrosoft, Apple, atau Google kemungkinan besar bahkan tidak akan mendiskusikan hal semacam ini
Mungkin Microsoft akan berkata “lupakan API lama, ini API baru”, Apple “wajib mulai ${WEIRD_NAME}”, dan Google “Anda tidak akan mendapatkan update itu”
Namun yang mengecewakan adalah renderer Vulkan hanya mencapai performa yang hampir sama dengan renderer GL lama
Ini tampak seperti tanda bahwa masalahnya ada di sisi pemanggil, bukan pada API 3D itu sendiri
Seharusnya performa dilacak dan diperbaiki secara iteratif sepanjang implementasi, bukan bersandar pada “kemurnian arsitektur”, yang tampaknya bukan ide bagus
Saya belum pernah melihat API rendering immediate mode diubah menjadi retained mode lalu menjadi lebih cepat
Dengan cara tertentu mungkin saja bisa, tetapi butuh pekerjaan luar biasa besar, dan untuk memperbaiki kasus patologis juga akan perlu perubahan di sisi klien API
Seingat saya, kebanyakan memakai MacBook mahal, jadi banyak masalah diabaikan dengan alasan “di komputer saya baik-baik saja”
Misalnya ada sejumlah masalah rendering font yang tidak memengaruhi layar Retina
Semoga ini tidak terdengar getir, tetapi sebagian besar pengembang engine grafis yang bagus sudah pernah membuat renderer yang beberapa generasi lebih maju daripada renderer toolkit GUI open source
Di antara kami ada beberapa orang yang bisa membawa rendering generasi berikutnya yang sesungguhnya ke desktop open source, tetapi kami bekerja di perusahaan pengembang game dan itulah yang menafkahi kami
Tidak ada waktu untuk berkontribusi ke stack open source
Jika komunitas bisa mengorganisir anggaran untuk membayar pengembang seperti ini secara rutin, pembaruan renderer dan toolkit akan sangat berbeda
Hal yang sama juga berlaku untuk aplikasi open source lain
Grafis 2D sangat sedikit kesamaannya dengan engine game
Dalam 2D, input biasanya berupa Bezier dan spline lain, overdraw-nya banyak, dan manajemen memori VRAM menjadi rumit karena tekstur yang disediakan pengguna
Sebaliknya, engine game memecahkan masalah sulit yang tidak berkaitan dengan renderer 2D, seperti pencahayaan dinamis, efek volumetrik, dan lingkungan dinamis
Rasanya toolkit UI game dan framework GUI desktop hidup di dunia yang berbeda dengan ekspektasi yang berbeda
Dari pengalaman saya memakai keduanya dalam karier saya, GTK/Qt biasanya baik atau sangat baik dalam menangani fitur seperti integrasi sistem operasi, aksesibilitas, navigasi keyboard, dan salin/tempel
Toolkit UI game sering kali sama sekali mengabaikan hal-hal ini karena tidak membutuhkannya, dan sebagai gantinya berfokus pada performa, tema, dan integrasi dengan engine game
Secara teori renderer bisa dibilang independen dari bagian-bagian itu, tetapi dalam praktiknya tidak sepenuhnya begitu
Saat anggaran terbatas, fitur mana yang diberi waktu juga berbeda
Renderer yang sangat cepat dan akurat tidak sepenting itu dalam framework GUI desktop dibandingkan dalam toolkit UI game
Berapa banyak yang mendukung CMYK dan satuan cetak?
Itu baru menggores permukaan hal-hal yang diperlukan renderer GUI tetapi tidak diperlukan engine game
Saya sangat skeptis bahwa para pengembang game bisa berkumpul lalu dengan mudah membuat sesuatu yang jauh lebih cepat daripada Skia tanpa mengorbankan banyak fitur
Orang-orang yang harus mencari nafkah, tetapi berkontribusi sejauh yang mereka bisa dengan memakai perangkat lunak dan sesekali menyumbangkan kode
Tentu, kalau komunitas bisa mengumpulkan dana, itu bagus, tetapi pekerjaan koordinasinya sendiri juga menjadi sesuatu yang tidak menafkahi seseorang
Saya menyukai open source/perangkat lunak bebas, bersyukur atas keberadaannya, dan juga berkontribusi ketika bisa, tetapi sejak lama saya menganggap ini sebagai kegiatan orang-orang yang punya privilese
Anda harus punya waktu luang, bisa memakai waktu luang itu untuk sesuatu yang tidak meningkatkan taraf hidup, dan bisa melakukannya secara konsisten
Saya bekerja di industri game, dan meski renderer 3D sangat bagus, saya belum pernah melihat renderer UI 2D yang terasa kompetitif
Apa yang mereka pakai untuk rendering path dan pattern?