Canvas vs WebGL: Tarayıcıda Görselleştirmenin İki Yüzü

Canvas 2D — Çiz ve Unut (Immediate Mode)

Tarayıcı bize tek bir <canvas> yüzeyi verir; ama bu yüzeye bağlandığın context seçimi, piksellerin hangi mantıkla üretileceğini belirler: 2d ile raster tabanlı çizim, webgl ile GPU pipeline.

Canvas 2D emir bazlıdır: fillRect(), stroke(), drawImage() dediğinde tarayıcı o an "boyar".

Sonuç, çoğu zaman "anlamlı nesneler" olarak değil; bir piksel çıktısı olarak kalır.

Bir daire çizdiğinde tarayıcı "dairenin" kendisini saklamaz; sadece boyanmış pikselleri görür.

Bu nedenle animasyon demek, her karede yeniden çizim demektir: sahnenin tamamını sen yönetirsin.

Buradaki kritik nokta şudur: Canvas 2D’de "sahne grafiği" yoktur.

Transform, opacity, "hangi obje nerede?" gibi durum bilgilerini sen tutarsın; tarayıcı çoğunlukla sadece emirlerin sonucunu pikselleştirir.

Bu, küçük işler için harika bir basitliktir; ama karmaşık animasyonlarda aynı işin kare kare yeniden üretilmesine yol açar.

Pratik sonuç: Canvas 2D’de performans çoğu zaman "daha az çiz" demektir: çizim alanını daraltmak, komut sayısını azaltmak ve pahalı işlemleri ( gölge, gradient, büyük metin ölçümü ) sınırlamak.

Güçlü yanı: Basit 2D grafikler, metin işlemleri, UI çizimleri ve hızlı prototipleme.

Zayıf yanı: Nesne/partikül sayısı yükseldikçe CPU her karede çok fazla karar + çizim çağrısı taşır; bu da ana iş parçacığını baskılar.

Bir de "çözünürlük faturası" var: devicePixelRatio yükseldikçe, netlik için canvas’ın gerçek çözünürlüğünü büyütürsün; raster alanı arttıkça kare başına boyanan piksel sayısı da artar.

Bu yüzden Canvas 2D animasyonlarında kalite–akıcılık dengesi daha serttir.

WebGL — Veri Yükle ve Koştur (Pipeline)

WebGL’de amaç tek tek "piksel boyamak" değil; bir grafik boru hattı kurmaktır.

Önce veriyi buffer olarak GPU’ya yüklersin; sonra bu verinin nasıl işleneceğini shader programlarıyla tarif edersin.

Bir draw call verdiğinde "aynı programın binlerce kopyası" GPU’da paralel yürür.

Bu model, 3D’nin doğal maliyetini ( çok sayıda piksel, çok sayıda üçgen, çok sayıda örnekleme ) daha doğru yere taşır.

Buradaki asıl fark, verinin ikametidir: geometri ve dokular GPU belleğine yerleştikten sonra, çoğu karede sadece uniform gibi küçük parametreler güncellenir.

Yani sahneyi her kare "yeniden çizmek" yerine, GPU’da tutup küçük farklarla yürütmek mümkün olur.

Doğru Okuyuş: WebGL "daha hızlı Canvas" değildir; farklı bir sözleşmedir: CPU hazırlığı yapar, GPU tekrarlı işi yürütür.

Bu ayrımı GPU vs CPU sayfasındaki "filozof vs ordular" fikriyle birlikte okuduğunda, hangi yükün nereye ait olduğu netleşir.

Güçlü yanı: Büyük ölçekli geometri, derinlik testi, ışıklandırma, post-process gibi işler donanım hızlandırmasıyla yürür.

Kritik maliyet: Kurulum daha ağırdır; "tek üçgen çizmek" bile buffer + shader + state düzeni ister.

Bu yüzden WebGL’de başarı, "kodu uzatmak" değil; veriyi doğru yerleştirmek ve draw çağrılarını disipline etmektir.

Bu disiplinin pratik ölçütleri şunlar olur: az state değişimi, az draw call, az gereksiz buffer upload.

Yani çoğu performans problemi shader mikro optimizasyonundan önce, CPU→GPU köprüsündeki gereksiz veri taşımaya takılır.

2D Çizim = Raster; 3D Çizim = Programlanabilir Pipeline

Canvas 2D çoğu zaman "boya" yaklaşımını temsil eder: pikselleri doğrudan üretirsin. WebGL ise "küçük bir program yaz, bunu çok kez çalıştır" yaklaşımıdır: aynı shader milyonlarca piksel üzerinde tekrar yürür.

Bu fark, "çıktı" ile "kural" arasındaki farktır: Canvas 2D’de çoğu zaman hedef, pikselleri mümkün olduğunca hızlı boyamaktır; WebGL’de hedef, pikselleri üreten kuralları kurup bunu paralel şekilde koşturmaktır.

Bu yüzden WebGL’de küçük bir matematik, ekranda devasa bir etki olarak büyüyebilir.

Raster yaklaşımda "aynı görünümü" elde etmek için çoğu zaman daha fazla komut verirsin; shader yaklaşımında ise aynı görünüm çoğu zaman daha az komut, daha çok paralel yürütme ile çıkar.

Mini sezgi: Eğer problem "çok sayıda benzer şey" ise ( partiküller, tile’lar, piksel efektleri ), shader/pipeline modeli doğal olarak güçlüdür.

Eğer problem "az sayıda öğe ama çok farklı kural" ise , Canvas 2D hâlâ pratik kalabilir.

İçerik Odağı: Bu farkı doğru kurduğunda, optimizasyon sırası da netleşir: Canvas’ta "daha az çizim", WebGL’de

"daha az state değişimi + daha iyi veri yerleşimi".

Bu yüzden iki dünyada "bottleneck" farklı görünür: Canvas tarafında CPU’nun çizim emirlerini yetiştirememesi baskındır; WebGL tarafında ise çoğu zaman köprü trafiği baskındır.

3D’nin Kalbi: "Kim Önde?" Problemi

3D sahnede en temel problem "hangi yüzey önde?" sorusudur.

Canvas 2D’de bunun karşılığı, çoğu zaman çizim sırasıdır: önce çizdiğin arkada, sonra çizdiğin önde görünür.

Basit sahnelerde bu yaklaşım idare eder; ama karmaşık bir modelde yüzeyler birbirinin içinden geçer, kameraya göre sıralama sürekli değişir ve çizim sırasını her karede doğru kurmak hızla bir matematik + veri yapısı problemine dönüşür.

Üstelik bu sadece "sırala ve çiz" kadar basit değildir: şeffaf objeler, parçacıklar ve iç içe geçmiş yüzeyler devreye girince sıralama kuralı da dallanır.

Bir yandan doğru görünürlük isterken, diğer yandan her karede N öğeyi yeniden sıralama maliyeti oluşur.

Gizli fatura: Canvas 2D’de 3D benzeri bir sahne kurmaya çalıştığında "overdraw" (aynı pikselin defalarca boyanması) çok hızlı büyür.

Derinlik testi olmadığı için, arkada kalacak pikselleri bile üretirsin; sonra en son çizdiğin üstte görünür. Bu, CPU’da boşa giden iş demektir.

WebGL Çözümü: Depth Buffer Donanım Düzeyinde

WebGL’de depth buffer, her piksel için "en yakın" değeri tutar.

GPU üçgeni raster ederken derinliği test eder; arkada kalan fragmanlar otomatik elenir ve bu, 3D’nin olmazsa olmazıdır.

Bu mekanizma "görsel doğruluk"tan fazlasını sağlar: sahnenin büyük kısmı ekranda görünmüyorsa, GPU görünmeyen fragmanları erken eleyebilir.

Yani depth buffer, 3D’nin hem doğruluk hem de verimlilik sigortasıdır.

Projection: 3D Uzayı 2D Ekrana İndirme

Diğer kritik parça projeksiyondur: 3D noktaları 2D ekrana "perspektif" ile yansıtmak için matris çarpımları gerekir.

WebGL’de bu iş vertex shader içinde GPU’da ölçeklenir.

Canvas tarafında ise bu çarpımlar CPU’da yapılır ve maliyet, sahnedeki nokta/üçgen sayısıyla lineer artar: her karede binlerce nokta dönüştürmek, ardından 2D primitive’lere döküp raster etmek zorundasın.

Bu yüzden Canvas’ta 3D; "geometri + perspektif" işini bir süre taşır, ama ölçek büyüyünce sürdürülebilir olmaz.

Canvas 2D ile 3D yapmaya çalıştığında bu hesaplar CPU’ya biner; üstüne bir de görünürlük ve sıralama eklenir.

Sonuç olarak , "çalışır" ama sürdürülebilir performans üretmez.

Pratik Karar Kuralı: Eğer sahnende "derinlik" gerçek bir ihtiyaçsa ( kamera dolaşıyor, objeler birbirini kapatıyor,

perspektif hissi kritik ), Canvas’ı zorlamak yerine pipeline’a geçmek daha doğrudur.

Çünkü burada mesele sadece hız değil, doğru model ile çalışmaktır.

Amaç "Çizmek" Değil, Dünya Kurmak

HoloDepth yaklaşımında hedef sadece "ekrana bir şey koymak" değildir; etkileşimli bir dünya kurmaktır.

Bu hedef, veriyi bir kez GPU’ya yerleştirip orada tutabilen; güncellemeleri küçük parametrelerle ( uniform vb. ) sürdürebilen pipeline modelini öne çıkarır.

Bu yüzden seçim, Canvas 2D’nin pratikliği değil; WebGL’in buffer ikameti ve depth/projection disiplinidir.

Bu farkı GPU vs CPU sayfasındaki iş bölümüyle birlikte okuduğunda "neden GPU tarafına devretmek gerekir?" daha net oturur.

"Bridge to Core" ifadesi burada şunu anlatır: WebGL seçimi, sadece bir render API seçimi değildir; uygulamanın veri akışını ve yaşam döngüsünü belirleyen bir çekirdek karardır.

Çünkü pipeline kurduğunda, sahnenin "ne olduğu" ile "nasıl çizildiği" ayrışır; bu ayrım da mimariyi büyütürken sürdürülebilirlik sağlar.

Mimari sezgi: Core katmanı CPU tarafında "dünyanın durumu"nu yönetir; render katmanı GPU tarafında "görünüm"ü üretir (pipeline, materyal, ışık, post-process).

İkisi arasında taşınan veri ne kadar küçük ve düzenliyse, kare bütçesi o kadar stabil olur.

Pratik sonuç: WebGL tarafında resize ve pixelRatio yönetimi; viewport ve render target güncellemesiyle daha doğru bir zemine oturur.

Bu "core" düzenini de Core & Script Base içinde adım adım kuruyoruz.

Ayrıca bu düzen, "her karede her şeyi yeniden üretme" refleksini kırar: çoğu varlık GPU’da ikamet eder; core tarafı ise yalnızca değişenleri günceller.

Bu yaklaşım, hem performansı hem de kod organizasyonunu aynı anda iyileştirir.

Kontrol listesi (kısa): Eğer 3D web projen büyürken takılma artıyorsa çoğu zaman cevap şuradadır:

• Gereksiz buffer upload var mı?
• Sahnede gereksiz state/material değişimi var mı?
• Draw call sayısı "sahne boyutu" ile orantısız mı? Bu soruların yanıtı, shader’dan önce core köprüsünü iyileştirmeni söyler.

Kısacası: 3D web’de doğru soru "hangisi daha kolay?" değil; "hangisi 3D’nin doğal ihtiyaçlarını donanım seviyesinde çözer?" sorusudur.

Cevap çoğu senaryoda WebGL olur.

Aynı kıyası canlı görmek için aşağıdaki Sistem Terminali kartından HoloDepth laboratuvarına geçebilirsin.