GTK için yeni renderlayıcılar
(blog.gtk.org)- GTK’nin renderlama temeli, GL için ngl ve Vulkan için vulkan olarak yeniden düzenleniyor; iki renderlayıcı aynı kaynaktan derlenen birleşik bir yapıya sahip
- Ortak uygulama, Vulkan API akışını temel alarak GL 3.3+ ve GLES 3.0+ farklarını soyutluyor; sahne grafı gezintisi ve önbellek gibi renderlama altyapısını birlikte kullanıyor
- Yeni renderlayıcılar şimdilik hızdan çok doğruluğa ve bakım kolaylığına öncelik veriyor; kenar yumuşatma, kesirli ölçekleme, sınırsız gradyan renk durakları ve dmabuf desteğini iyileştiriyor
- Uygulama geliştiricileri glshader düğümü desteğinin olmamasını, kesirli konum işleme değişikliklerini ve olası sürücü sorunlarını kontrol etmeli; sorun sürücü kaynaklı gibi görünse bile GTK tarafına bildirmek iyi olur
- GTK 4.13.6 snapshot’ında ngl yeni varsayılan olsa da bu hâlâ deneme aşamasında; büyük sorunlar çıkarsa GTK 4.14’te eski gl renderlayıcısına geri dönülebilir
GL ve Vulkan için birleşik renderlayıcı
- GTK, GL için yeni renderlayıcı ngl ve Vulkan için yeni renderlayıcı vulkan ekledi
- İki renderlayıcı aynı kaynaktan derlendiği için buna birleşik renderlayıcı deniyor
- Uygulama modeli Vulkan API’sini izliyor ve GL 3.3+ ile GLES 3.0+ arasındaki farkları ele almak için soyutlamalar içeriyor
- Bu yapı sayesinde, renderlayıcı başına ayrı ayrı sürdürülen temel işler paylaşılabiliyor
- Sahne grafı gezintisi
- Dönüşümlerin ve diğer durumların korunması
- Doku ve glif önbellekleri
- İki renderlayıcıyı güncel ve uyumlu tutma çalışması
Metal ve DirectX’e genişletirken gereken koşullar
- Aynı yaklaşımı macOS’ta Metal tabanlı bir renderlayıcıya veya Windows’ta DirectX tabanlı bir renderlayıcıya genişletme olasılığı var
- Vulkan ve GL, temelde aynı shader dili olan GLSL’i paylaşmaları açısından avantajlı
- Metal veya DirectX için aynı koşul geçerli değil; shader’ları mükerrer yazmak ya da SPIRV-Cross gibi dönüştürme araçları kullanmak gerekiyor
- Bu çalışmayla ilgilenen katkıcılar memnuniyetle karşılanır
Uygulama yaklaşımı ve ubershader
- Mevcut GL renderlayıcısı her rendernode türü için basit bir shader kullanıyor ve karmaşık içeriklerde sık sık offscreen renderlamaya dayanıyor
- Birleşik renderlayıcı da daha güçlü düğüm başına shader’lara sahip; ancak offscreen yerine tampon verilerini yorumlayan karmaşık shader’ları da birlikte kullanıyor
- Oyun programlamada bu yaklaşıma ubershader deniyor
- Yeni uygulama mevcut GL renderlayıcısına göre daha az optimize edilmiş olsa da doğruluk ve bakım kolaylığına öncelik vererek daha çeşitli rendernode ağaçlarını doğru şekilde işleyebiliyor
Renderlama kalitesi ve yeni özellikler
-
Kenar yumuşatma
- Mevcut GL renderlayıcısı, piksel satırı sınırları arasına sığacak kadar küçük ayrıntıları kaybedebilir
- Bu sorun, mnemonic gibi alt çizgileri de etkileyebilir
- Birleşik renderlayıcı küçük ayrıntıları daha iyi korur ve primitive dış hatlarındaki merdivenlenmeyi de azaltır
-
Kesirli ölçekleme
- Kenar yumuşatma, kesirli ölçeği doğru işlemenin temelini oluşturur
- 1200×800 bir pencereyi %125 ölçeklerken birleşik renderlayıcı 1500×1000 framebuffer kullanır
- Bu, compositor’ın 2400×1600 görüntüyü downscale etmesine bırakılan yaklaşıma göre çok daha az piksel işler ve görüntü daha nettir
-
İsteğe bağlı gradyanlar
- Mevcut GL renderlayıcısı doğrusal, radyal ve konik gradyanlarda en fazla 6 renk durağı işleyebilir
- Birleşik renderlayıcı renk durağı sayısını sınırsız olarak kabul eder
- Gradyanlara da kenar yumuşatma uygulayarak keskin sınırlarda yumuşak çizgiler oluşturur
-
dmabuf
- GTK geçen sonbaharda dmabuf desteği ve grafik offloading çalışmaları yaptı
- Yeni renderlayıcılar bunu destekliyor ve render_texture API’siyle doku oluşturma istendiğinde dmabuf oluşturabilecek şekilde genişletiyor
- Şu anda bu genişletme yalnızca Vulkan renderlayıcısı için geçerli
Uygulama geliştiricilerinin kontrol etmesi gerekenler
-
glshader düğümü desteklenmiyor
- glshader düğümü GTK 4.0 demosu için kullanışlıydı, ancak mevcut GL renderlayıcısına güçlü biçimde bağlı
- Bu düğüm, mevcut renderlayıcının sunduğu GLSL API’sini varsayar
- Yeni renderlayıcılar glshader düğümünü desteklemiyor
- GTK belgeleri, shader’lara bağımlı olmadan önce doğrulama yapılmasını; başarısız olursa daha basit bir shader ya da shader’sız bir alternatif yol kullanılmasını öneriyor
- GTK 4.0’dan sonra mask düğümü ve straight-alpha doku desteği gibi özellikler eklendiği için birçok glshader düğümü kullanım senaryosuna artık gerek kalmadı
-
Kesirli konumlar
- Mevcut GL renderlayıcısı konumları yuvarladığı için kesirli konumlar verilse bile sorun görünmeyebiliyordu
- Yeni renderlayıcılar öğeleri belirtilen konuma aynen yerleştirir
- Bu fark istenmeyen sonuçlar doğurabilir; bu yüzden konumun istenen değer olduğundan emin olunmalı
- Özellikle bir piksel satırını tam doldurmak için çizgiyi yarım piksel konumuna yerleştiren cairo tarzı çizimlere dikkat edilmeli
-
Sürücü sorunları
- Yeni renderlayıcılar grafik sürücülerini yeni ve farklı bir şekilde kullandığından sürücü tarafında sorunları tetikleyebilir
- Sorun sürücü hatası gibi görünse bile GTK’ye bildirmek iyi olur
- Bu, yeni kodun farklı sürücüler ve donanımlarda ne kadar iyi çalıştığını anlamaya yardımcı olur
Mevcut performans durumu
- Yeni renderlayıcılar henüz mevcut renderlayıcıdan hızlı değil
- Mevcut GL renderlayıcısı hız için yoğun biçimde optimize edilmiş, daha basit shader’lar kullanıyor ve kenar yumuşatma gibi özellikler için gereken hesaplamaları yapmıyor
- Hedef, yeni renderlayıcıları sonunda daha hızlı yapmak; ancak şu anda yeni özellikler ve doğruluk daha büyük iyileştirmeler
- Tüm GPU tabanlı renderlayıcılar, GTK uygulamalarını 60fps veya 144fps’de renderlamak için şu anda yeterince hızlı
- Bilimsel olmayan benchmark’larda Vulkan renderlayıcısı mevcut GL renderlayıcısına benzer ya da bazı durumlarda onu geçmeye yakın düzeyde
- Yeni GL renderlayıcısının neden daha yavaş olduğu henüz izlenip bulunmadı
Varsayılan değişikliği ve istisnalar
- Yeni yayımlanan GTK 4.13.6 snapshot’ında ngl renderlayıcısı yeni varsayılan oldu
- Bu değişiklik deneme amaçlıdır; üretime hazır olup olmadığını görmek için birçok uygulamada daha geniş testlerden geçmesi gerekiyor
- Büyük sorunlar ortaya çıkarsa GTK 4.14’te mevcut gl renderlayıcısına geri dönülebilir
- Vulkan renderlayıcısı henüz varsayılan değil
- WebKit GTK4 portu GL’de çalışıyor, ancak Vulkan’da çalışmıyor
- GtkGLArea ve GtkMediaStream şu anda GL dokuları oluşturuyor; Vulkan renderlayıcısı bunları doğrudan içe alamıyor
- Bu sorunlar yakın gelecekte çözülürse varsayılan renderlayıcı kararı yeniden değerlendirilecek
- GTK’yi çok eski donanımlarda kullanıyorsanız mevcut GL renderlayıcısı daha iyi olabilir
- Mevcut GL renderlayıcısının GPU’dan beklentileri daha düşüktür
- Renderlayıcı seçimi
GSK_RENDERERortam değişkeniyle geçersiz kılınabilir - Örnek:
GSK_RENDERER=gl
Gelecekte yapılabilecek işler
- Yeni renderlayıcılar, uzun zamandır istenen özellikleri uygulamak için bir temel oluşturuyor
- Gelecekte yapılabilecek işler şunları içeriyor
- HDR dahil doğru renk işleme
- GPU’da path rendering
- Glif renderlamayı dahil etme olasılığı
- Ana thread dışında renderlama
- Eski ve daha az güçlü cihazlarda performans iyileştirmeleri
- Bazı maddeler kısa ve orta vadeli çalışmaların odağı olacak
- Yeni renderlayıcılar için daha fazla ek özellik planlanıyor; kullanıcılar bunları doğrudan deneyip çalışıp çalışmadığını bildirebilir
1 yorum
Hacker News yorumları
Uzun zaman önce, sanırım 2010 civarında, tarayıcının içinde GTK uygulamaları çalıştırıp UI'ı normal HTML+CSS ile oluşturan deneysel bir HTML renderer vardı diye hatırlıyorum
O zamanlar gerçekten sarsıcıydı; Atom, VS Code, Electron, hatta belki NodeJS bile çıkmadan önceydi sanırım
O renderer'ın hâlâ durup durmadığını bilmiyorum
https://docs.gtk.org/gtk4/broadway.html
https://www.phoronix.com/news/GTK4-Broadway-Being-Used
Ana akım/resmî backend olduğunu düşünmüyordum ama hâlâ duruyor ve Gtk4'e de port edilmiş
Çünkü tarayıcının sunduğu neredeyse her şeyi atıp baştan yapan saf canvas yaklaşımına daha yakın davranış özellikleri gösteriyor
Doğru davranışı değerlendirme ölçütleri genelde (a) tarayıcı kaydırmasını kullanmak, (b) tarayıcı metin render'ını kullanmak, (c) bağlantıları gerçek öğeler olarak ele almak; Broadway bu üçünün de hiçbirini başaramıyor
Kaydırmayı yeniden implemente ediyor, metni sunucuda render edip görüntü olarak gönderiyor ve bir bağlantıya tıklamaya çalışırsan gerçekten duruyor gibi görünüyor
Üstelik metin girişi de yalnızca tuş olaylarını kullanıyor gibi, bu yüzden IME kompozisyonu tamamen bozuluyor; klavye gezintisi de native değil GTK tarafında olma ihtimali yüksek
Erişilebilirlik ağacını da anlamlı şekilde sunamıyor
Teknik demo ya da sınırları kabul eden kişisel kullanım için fena değil, ama herkese açık dağıtım için uygun değil; fiilen biraz DOM kullanımı karışmış RDP/VNC türü bir şeye daha yakın
Kodun tamamının sunucuda çalıştığını da unutmamak gerek
Esasen piksel verisini canvas öğesine stream etme yöntemi, yani web görüntüleyicisi eklenmiş VNC ile neredeyse aynı
https://imgur.com/a/2EDZ2Ti
https://github.com/moondev/gtk3-docker
Benim kullanımım, tarayıcı içinde tarayıcı çalıştırıp port forwarding ya da proxy olmadan Kubernetes clusterip servisleriyle kolayca etkileşime girmekti
Bir başka güzel örnek de virt-manager'ı açıp gtk virt-viewer ile VM çalıştırmak ve tarayıcıdan kontrol etmek
https://github.com/m-bers/docker-virt-manager
GTK'nın başlık çubuğuna widget koyma akımını takip etmemesini isterim
Bazıları sürükleniyor, bazıları sürüklenmiyor; uygulama adı ve dosya adını gösterecek alan da azalıyor
Bu yalnızca GTK'ya yönelik bir şikâyet değil
Piksel düzeyinde doğru kesirli ölçeklendirme, güzel, yuhuu!
Artık Wayland'de düzgün desteklenirse, büyük Linux masaüstü ortamlarının tamamında HiDPI desteği mümkün olacak gibi
1200×800 bir pencereyi %125 ölçeklediğinde, birleşik renderer'ın compositor'ın 2400×1600 görüntüyü küçültmesine izin vermek yerine 1500×1000 framebuffer kullandığı yazıyor
Benim anladığım kadarıyla bu, %125 ölçek nedeniyle ekranda 1500×1000 piksel olarak çizilmesi gereken pencerenin uygulama pikselleri açısından 1200×800 olduğu anlamına geliyor
OpenGL ve Vulkan kayan noktayla render ettiği için, koordinat dönüşümüyle ekranda 1:1 render edilebilen bir buffer'a doğrudan çizmek yeterli demek istiyor olmalı
Eğer doğruysa, sonunda sağduyulu yöntem gibi görünüyor
Linux'ta masaüstü ortamlarının nasıl çalıştığını gerçekten anlayan biri var mı? Ben pek bilmiyorum
Giderek daha karmaşık ve yamalı bohça gibi geliyor
İstemci/sunucu yapısı, sonunda vardığımız yüksek derecede entegre grafik işleme modelinin tam tersiydi
X11'i erkenden bırakıp zararı azaltmak yerine, hem Unix tedarikçileri hem de açık kaynak tarafı çok uzun süre bir kamyon dolusu çürük limondan limonata yapmaya çalıştı
Linux GUI'sinin bu kadar geride kalmasının nedeni bu
Apple'ın X11'e bağlı kalmayıp entegre modeli benimsemesi sayesinde Unix GUI'yi hızla geliştirebilmesi dikkat çekici; artık kendi GPU'sunu bile tasarlıyor
Wayland mimarisinin ne kadar büyük etki yaratacağını ve gerçekten GNOME'a özel uygulamalar ortaya çıkıp çıkmayacağını merak ediyorum
Bir ANSI metin renderer’ı olsa iyi olurdu
GTK programlarını xterm’im içinde çalıştırabilmek, isteğe bağlı olarak biraz da sixel eklemek isterdim
Kenar çubuğu, başlık çubuğunda birkaç davranış, ayrıntı görünümü yapısı
Mac uygulamaları, “Modern” Windows uygulamaları ve mobil uygulamalar da benzer
UX toolkit’inin tamamen deklaratif ve semantik olup olamayacağını merak ediyorum
“Master/detail görünümü, şu alanlara sahip bir liste görünümü, birkaç davranış gerekiyor” gibi yüksek seviyede konum ya da stil vermeden, uygun sistem widget’larını otomatik kullanan bir yaklaşım
Bunun üzerine biraz CSS ya da native widget’lara kaçış yolu eklenebilir
Tarayıcılar, WYSIWYG editörler ve medya görüntüleyiciler dışındaki neredeyse tüm uygulamalar bu kalıba uyacak gibi; asıl nokta da böyle bir tanımdan kolayca TUI üretilebilmesi
https://github.com/fathyb/carbonyl
https://i.imgur.com/pIQ4K7Q.png
https://wgpu.rs/ kullanılsaydı DirectX ve Metal bedavaya gelirdi :)
Bu çalışma gerçekten eğlenceli görünüyor
Kenar yumuşatma kısmını okurken, oyun motorlarında olduğu gibi signed distance field’ların keyfi ölçeklerde yazı tipi render etmeye de iyi uyup uymayacağını düşündüm
Valve’ın bu konuda iyi bir makalesi vardı
Oyun renderer’larının UI kodlarında veya decal render etme tarafında, GUI kodu için de faydalı olabilecek pek çok hoş teknik var
Performans düşüşünün neden kabul edildiğini anlamıyorum
İşlerimin çoğunu eski donanımla yapıyorum; bu tür özellikleri kapatabiliyorsam kapatmak isterim, hatta GPU’mda desteklenmiyor bile olabilirler
Gözle görülür bir performans düşüşü varsa
GSK_RENDERER=glkullanılabilirMicrosoft, Apple, Google olsaydı muhtemelen bunları tartışmazdı bile
Muhtemelen Microsoft “eski API’yi unutun, işte yeni API”, Apple “${WEIRD_NAME} itibarıyla zorunlu”, Google ise “o güncellemeyi alamazsınız” derdi
Ama hayal kırıklığı yaratan nokta, Vulkan renderer’ın yalnızca mevcut GL renderer ile hemen hemen aynı performansa ulaşması
Bu, sorunun 3D API’nin kendisinden çok çağıran tarafta olduğuna dair bir işaret gibi görünüyor
Uygulama boyunca performansı izleyip yinelemeli olarak iyileştirmek gerekirdi; “mimari saflığa” güvenmek iyi bir fikir değildi gibi
Immediate mode rendering API’sini retained mode’a çevirip hızlandığını hiç görmedim
Bir şekilde mümkün olabilir, ama muazzam iş gerektirir ve patolojik durumları düzeltmek için API istemcisi tarafında da değişiklikler gerekir
Hatırladığım kadarıyla çoğu pahalı MacBook’lar kullandığı için “benim bilgisayarımda çalışıyor” diye geçiştirilen çok sorun var
Örneğin Retina ekranları etkilemeyen birçok yazı tipi render etme sorunu var
Kulağa buruk gelmesini istemem ama, iyi grafik motoru geliştiricilerinin çoğu açık kaynak GUI toolkit renderer’larından birkaç nesil ileride renderer’lar zaten geliştirmiş durumda
Aramızda açık kaynak masaüstüne gerçekten yeni nesil rendering getirebilecek birkaç kişi var, ama oyun geliştirme şirketlerinde çalışıyorlar ve geçimlerini bu sağlıyor
Açık kaynak stack’e katkı verecek zamanları yok
Topluluk bu geliştiricilere düzenli ödeme yapacak bir bütçe organize edebilirse, renderer ve toolkit güncellemeleri çok farklı bir noktaya gelebilir
Diğer açık kaynak uygulamalar için de aynı şey geçerli
2D grafiklerin oyun motorlarıyla çok az ortak noktası var
2D’de giriş olarak genelde Bézier eğrileri ve başka spline’lar gelir, overdraw fazladır ve kullanıcı tarafından sağlanan dokular nedeniyle VRAM bellek yönetimi karmaşıklaşır
Buna karşılık oyun motorları dinamik aydınlatma, hacimsel efektler, dinamik ortamlar gibi 2D renderer’larla ilgisi olmayan zor problemleri çözüyor
Oyun UI toolkit’leri ile masaüstü GUI framework’lerinin farklı beklentilere sahip ayrı dünyalarda yaşadığını düşünüyorum
Kariyerimde ikisini de kullanmış biri olarak, GTK/Qt’nin işletim sistemi entegrasyonu, erişilebilirlik özellikleri, klavye ile gezinme, kopyala/yapıştır gibi işlevleri genellikle iyi ya da çok iyi ele aldığını gördüm
Oyun UI toolkit’leri bunlara ihtiyaç duymadığı için çoğu zaman tamamen vazgeçiyor; bunun yerine performansa, temalara ve oyun motoru entegrasyonuna odaklanıyor
Teorik olarak renderer’ın bu kısımlardan bağımsız olduğu söylenebilir, ama pratikte tamamen öyle değil
Bütçe sınırlı olduğunda hangi özelliğe zaman ayrılacağı da farklılaşıyor
Çok hızlı ve doğru bir renderer, masaüstü GUI framework’leri için oyun UI toolkit’lerinde olduğu kadar önemli değil
Kaçı CMYK ve baskı birimlerini destekliyor?
Bunlar, GUI renderer’ları için gerekli olup oyun motorları için gerekli olmayan şeylerin yalnızca yüzeyini kazımak
Oyun geliştiricilerinin bir araya gelip Skia’dan çok daha hızlı, ama pek çok özellikten de fedakârlık etmeyen bir şeyi kolayca ortaya çıkarabileceği konusunda oldukça şüpheliyim
Geçimini sağlamak zorunda olan, ama yazılımı kullanıp arada kod katkısı vererek elinden geldiğince katkıda bulunan insanlar
Elbette topluluk fon toplayabilirse harika olur, ama o koordinasyon işi de birileri için geçimini sağlamayan bir iş haline geliyor
Açık kaynak/özgür yazılımı seviyorum, varlığına minnettarım ve mümkün olduğunda katkı da veriyorum; ama uzun zamandır bunun ayrıcalıklı insanların uğraşı olduğunu düşünüyorum
Boş zamanınız olmalı, o boş zamanı yaşam standardınızı yükseltmeyen bir işe ayırabilmelisiniz ve bunu sürdürebilmelisiniz
Oyun sektöründe çalışıyorum ve 3D renderer’lar çok iyi, ama rekabetçi denebilecek bir 2D UI renderer görmedim
Path ve pattern rendering için ne kullanıyorlar?