Performans ve Web Worker: decode işleminin görünmeyen maliyeti

Sıkıştırılmış bir bitstream’i tekrar anlamlı 3D koordinatlara çevirmek yoğun matematiksel hesap gerektirir. Kaba kural:

• Dosya ne kadar küçükse ağdan o kadar hızlı iner.
• Sıkıştırma ne kadar agresifse işlemcinin çözüm için yürüteceği iş o kadar artar.

Çok yoğun bir modeli (örneğin milyonlarca tepe) en üst Draco seviyelerinde paketlerseniz, dosya örneğin 2 MB olsa bile düşük bütçeli bir telefonda çözümleme birkaç saniye sürebilir — bu süre cihaza, sıcaklığa ve eşzamanlı iş yüküne göre değişir.

Akış (streaming) vs. bloklama: Draco mesh decode’u tipik kullanımda «yarım topolojiyi çiz» şeklinde ilerlemez; tampon hazır olana kadar beklenir — yani ağ tarafı parça parça gelse bile çözümleme tarafı çoğu zaman bloklayıcı bir his üretir. Sınırın tam metni için yine decode performans tuzakları bölümüne dönün.

Modern tarayıcılarda JavaScript çoğu kullanıcı arayüzü işinde tek ana iş parçacığı (single-threaded his) üzerinden akar: kaydırma, tıklama ve sahne döngüsü aynı «ana yol» ile yarışır. Tarayıcı, görevleri call stack + kuyruklar üzerinden işleyen event loop ile yürütür; ana iş parçacığında uzun süren senkron iş (long task) birikince giriş olayları ve requestAnimationFrame (rAF) gecikir — kullanıcı bunu düşük FPS veya takılma olarak hisseder.

Ana iş parçacığında decode (riskli yol)

Draco çözümlemesini ana iş parçacığında çalıştırırsanız, işlemci o süre boyunca decompress’e odaklanır; event loop üzerindeki diğer görevler sıraya girer. Sonuç: model yüklenirken sayfa akıcı kaymaz, etkileşim gecikir, varsa animasyonlar «tırtıklanır». Buna kısaca UI donması (freezing) denebilir.

Web Worker (güvenli yol)

Web Worker, tarayıcıda arka planda çalışan ayrı bir JavaScript kanalıdır. DRACOLoader sıkıştırılmış veriyi ana iş parçacığından alıp bir worker’a iletir; çözümleme arka planda, arayüz akışını kesmeden yürür. Model hazır olduğunda sahneye sessizce oturur; kullanıcı sayfada gezinmeye devam edebilir.

GPU yükleme ve kare süresi

Worker decode CPU yükünü ana yoldan ayırır; fakat geometri hazır olduğunda tamponların grafik sürücüsüne aktarılması (buffer upload, texture / geometry yolu) çoğu zaman yine ana iş parçacığı ve grafik kuyruğu üzerinden işlenir. Büyük tek seferlik yüklemeler, bir veya birkaç karede frame time bütçesini (örn. 60 FPS için kabaca 16,7 ms / kare) aşıp kare sıçraması (frame spike / düşük FPS anı) üretebilir. Yani «decode bitti» demek, aynı anda «kare pürüzsüz» demek değildir.

Mobilde performans yönetimi yalnızca «hız» değil, cihaz sağlığı demektir.

• Isınma (thermal throttling): Yoğun Draco decompress dalgaları işlemciyi anlık olarak yüksek kullanıma iter. Sayfada çok sayıda ağır model varsa cihaz ısınır; işletim sistemi saat hızını düşürerek performansı otomatik kısabilir.
• Batarya: CPU’nun sürekli yoğun çalışması tüketimi artırır. Mobil odaklı sitelerde niceleme (quantization) bitlerini gereğinden agresif tutmamak, işlemci yükünü kontrol altında tutmanın pratik yollarından biridir.
• RAM sınırı: Sıkıştırılmış veri bellekte az yer tutar; açıldığında (decompressed) geometri yine kendi hacmine yaklaşır. Mobil tarayıcılar bellek baskısında sekmeyi sonlandırabilir.

Performans ile kullanıcı deneyimi arasında denge için aşağıdaki ilkeler işe yarar:

• Decoder havuzu ve batching: Aynı anda çok modeli «her birine bir worker» diye saldırmak yerine, uygulama düzeyinde bir kuyruk (queue) tutun: sınırlı sayıda decode işi yürüsün, biten yerine sıradaki gelsin. Böylece hem CPU’yu doyurmazsınız hem de kare süresine yansıyan upload dalgalarını yayılmış zamanlara dağıtma şansınız artar.
• Öncelik (priority): Kuyrukta hangi modelin önce çözüleceğini açıkça tanımlayın: örneğin kullanıcının baktığı nesne, LOD0, ardından arka plan; veya etkileşim bekleyen varlıklar önce, dekorasyon sonra. «İlk gelen ilk çözülür» varsayılanı çoğu zaman optimal değildir.
• Worker sayısı ve çekirdekler: Fiziksel çekirdek üstünü aşan eşzamanlı ağır iş, genelde verim yerine bağlam değişimi (context switch) ve ısı maliyeti getirir. Tarayıcıda elinizdeki üst sınır ipucu için navigator.hardwareConcurrency (mantıksal iş parçacığı sayısı; her zaman fiziksel çekirdek değildir) kullanılabilir; buna göre setWorkerLimit’i kısın veya küçük bir pay bırakın:

const cores = navigator.hardwareConcurrency || 4;
dracoLoader.setWorkerLimit(Math.max(1, Math.min(4, Math.floor(cores / 2))));

Üstteki sayılar örnektir; ölçüm ve cihaz testi şarttır.

• Ertelemeli decode (lazy decoding): Yalnızca kameranın görüş kesiti (frustum) içine giren veya kullanıcının etkileşime geçtiği modelleri çözün; sahne geri kalanını bekletin.
• WASM önceliği: Draco çözücünün .wasm ve eşlik eden .js dosyalarını hızlı önbellek veya CDN ile servis edin; çözücünün geç inmesi, model dosyası elinizde olsa bile decode’u geciktirir.

Draco bize ağ tarafında hız kazandırır; Web Worker ise bu kazancın arayüzde akıcılığa dönüşmesini sağlar. Holodepth’te hedef, yalnızca hızlı inen dosyalar değil; WASM + worker + GPU upload zincirinde frame time bütçesini gözeterek yağ gibi akan bir arayüz için bu arka plan katmanlarını bilinçle yönetmektir.