Limitler ve trade-off: hızın görünmeyen bedeli

Draco’nun en büyük limiti, veriyi çözmek (decompress) için ihtiyaç duyduğu yoğun CPU gücüdür.

Matematiksel yoğunluk

Sıkıştırılmış teli yeniden 3B koordinatlara dökmek; çok sayıda dequantization ve connectivity (bağlantı) hesabını içerir — basit bir «kopyala-yapıştır» değildir.

WASM sınırı

WebAssembly hızlı olsa da, çözüm anındaki iş yükü aynı çip üzerinde fizik motoru, ses, UI etkileşimi gibi diğer görevlerle yarışır; ana iş parçacığı veya işçi düzenine göre hissedilir şekilde gecikme üretebilir.

Isınma ve throttling

Özellikle mobilde arka arkaya ağır Draco modellerini çözmek işlemciyi ısıtır; cihaz thermal throttling ile hızı düşürür. Bu da sonraki dosyaların daha yavaş çözülmesine yol açan bir kısır döngü başlatabilir.

Draco her zaman tasarruf sağlamaz: dosya küçülse bile, ana iş parçacığında uzun süren decode bloklamayı artırır (ör. Lighthouse ölçümlerinde Total Blocking Time (TBT)); kullanıcı «hâlâ donuyor» hissini yaşar.

Decoder kütüphane yükü

Draco decoder (WASM + JS) tarayıcıya kabaca 150–200 KB ek getirir; sürüme ve paketlemeye göre değişir.

Matematiksel zarar eşiği

Modeliniz (örneğin basit bir kutu veya düşük poligonlu bir ikon) zaten 50 KB civarındaysa, onu Draco ile 5 KB’a indirmek için 150 KB’lık çözücü yüklemek genelde mantıksızdır.

Altın kural (kaba)

Toplam model (veya aynı anda yüklenen modellerin toplamı) kabaca ~500 KB altındaysa Draco çoğu zaman kaş yaparken göz çıkarmak riski taşır — ölçüm yapmadan varsaymayın; Karar sayfası · red flag ile çapraz kontrol edin.

Birçok ekip Draco’yu RAM dostu sanır; oysa çözüm anında durum farklıdır.

• Sıkıştırılmış veri: RAM’de görece az yer tutar.
• Çözümleme süreci: Aynı anda hem sıkıştırılmış tel hem de açılmakta olan ham ara temsil bellekte bulunur.
• Final mesh: Çözüldükten sonra model, telde tasarruf etseniz bile çalışma zamanı temsili orijinal (sıkıştırılmamış) boyutuna yaklaşır.

Risk: Düşük bellekli mobilde büyük bir Draco dosyasını açarken tarayıcının out of memory ile çökme ihtimali, aynı geometriyi ham taşıyan standart glTF’e kıyasla bazen daha yüksek görülebilir — ölçüm şart. Ayrıntı için Draco vs. standart · bellek sıçraması.

Draco’nun kayıplı (lossy) doğası, hassas verilerde sorun çıkarabilir.

Jittering (titreme)

Quantization bitleri düşükse yüzeyde mikroskobik titremeler oluşur; statikte fark edilmeyen bu «geometrik gürültü», animasyonda rahatsız edici olur — Vertex quantization.

UV kaymaları

Doku koordinatlarındaki milimetrik kaymalar, çizgi ve dikiş (seam) bölgelerinde belirginleşebilir — UV bitleri reçetesine bakın.

Aşağıdaki başlıklar üstteki bölümleri yeniden yazmaz; yalnızca üretimde sık atlanan ince ayar hatlarını tamamlar. Ayrıntı tekrarından kaçınmak için mümkün olduğunda mevcut derin sayfalara bağlanır.

Decode bittiği anda büyük vertex / indeks tamponlarının GPU’ya aktarılması (upload), kısa süreli bir upload spike üretebilir. Bu iş, özellikle ana iş parçacığında veya sıkı kare bütçesinde decode ile aynı kareye denk gelirse frame drop olarak hissedilir. Çizgi diyagramı: Draco vs. standart · GPU upload; pratik ölçüm için GPU ve CPU izlerini ayrı kanallardan okuyun.

Çözüm işi pratikte sınırlı sayıda Web Worker üzerinden yürür; varlık sayısı arttıkça bekleyen işler bir kuyruk oluşturur. Three.js tarafında setWorkerLimit ile havuz boyutu seçilir; limit düşükse indirme paralel olsa bile decode sıraya girer — kuyruk disiplini (öncelik, batch boyutu, ana iş parçacığına geri dönüş zamanlaması) toplam süreyi belirler. Çok varlıklı sahne notu · Karar sayfası · kuyruk özeti · Performans ve Web Worker.

Tipik Draco mesh yükü, tek başına «akış halinde yarı çözülmüş geometri göster» modeli sunmaz; kademeli içerik beklentiniz varsa teslim mimarisini (dosya bölme, LOD, sahne grafiği) ayrı tasarlamanız gerekir — Streaming başlığı.

Bölüm 3’teki RAM sıçraması geçtikten sonra, ara tamponların serbest bırakılması tarayıcıda GC baskısı doğurabilir; mobilde bu duraklamalar bazen decode’dan bağımsız olarak hissedilir. Tahmini süre zor olduğundan profiler ile doğrulama önerilir — özellikle arka arkaya büyük modeller açılıyorsa.

60 FPS hedefinde kabaca ~16,7 ms / kare üst sınırı düşünün; decode, ana iş parçacığı senkronizasyonu ve ardından gelen upload aynı pencerede yer kaplıyorsa kare süresi hemen taşar. VR / düşük güç profillerinde bu bütçe daha da sıkıdır — Karar sayfası · kare bütçesi.

Aynı anda çok sayıda ağır decode + büyük upload, çipi doygunlaştırır (CPU saturation): işçiler meşgulken kuyruk büyür, sıcaklık yükselir (bölüm 1 · throttling), kare süresi dalgalanır. Çözüm tek başına «daha agresif sıkıştırma» değil; yük zamanlaması ve öncelik sırasıdır — Draco vs. standart · çok varlık.