holodepth

HTML5 Canvas · 2D–WebGL köprüsü

Canvas limitleri: 2D API’nın tasarım kenarları ve taşma noktaları

Canvas 2D güçlü ve üretken bir yüzeydir; fakat tasarımı anında çizilen soyutlama, donanım derinlik tamponunun olmaması ve piksel geri okumasının maliyeti gibi sınırları içerir. Bu sayfa «Canvas kötüdür» demez — Canvas’ın nerede doğal olarak daraldığını Canvas geliştiricisi gözüyle sabitler ve WebGL köprüsünün hangi gerekçelerle devreye girdiğini netleştirir. Komşu içerikler soyutlamayı tamamlar: CPU ve GPU rolleri, İş hattı farkları, Neden WebGL?

Piksel bütçesi ve bağlam sıçraması gibi performans düşüncesi Yeniden çizim maliyeti ile işlenir — burada «neden bu API ile belirli işler zordur?» sorusuna odaklanılır; aynı başlığı tekrar ölçüm teknikleriyle doldurmuyoruz.

Özet: limit mi yoksa yanlış beklenti mi?

Alan Canvas 2D gerçeği Sık taşma belirtisi
Görünürlük Derinlik tamponu yok Karmaşık 3B sıra patlar
Geri okuma Piksel CPU’ya senkron aktarılır Her kare tampon okuma
Programlanabilirlik Sabit raster modeli Özel piksel matematiği zinciri

Komut sırasına bağlı soyutlama modeli

Canvas 2D’de sahne durumu CanvasRenderingContext2D üzerinde tutulur ve çizim komutları sırayla yorumlanır — bu «anında mod» ( immediate mode ) hissi verir. Bu model okunabilirlik sunar; fakat çok katmanlı sahne ve karmaşık öncelik kuralları için komut sırası ile iş mantığını sıkı bağlamak gerekir. Üst düzey bir sahne grafiği ( scene graph ) kendi başına tarayıcı tarafından saklanmaz; her şeyi siz düzenlersiniz veya bir motor katmanı yazarsınız.

Köprü düşüncesi: WebGL tarafında da CPU komut gönderir fakat geometri ve görünüm çoğu zaman tamponlar ve gölgelendiricilerle önceden paketlenir — soyutlama seviyesi farklıdır. Canvas’ta «aynı görünümü» sürdürmek için çoğu zaman daha fazla elle sıralama ve önbake katman üretimi gerekir. Offscreen Canvas ile bu yük yumuşatılabilir; API limiti ortadan kalkmaz.

Bağlam özellikleri ( globalCompositeOperation, filter, shadowBlur … ) güçlüdür; yanlış kombinasyonlar öngörülebilirlik ve performans sorunları doğurur — 2D bağlam düşüncesi ile birlikte okunmalıdır.

Derinlik tamponu olmadan görünürlük ve sıralama yükü

Canvas 2D bağlamında donanım düzeyinde Z-test ile çalışan bir derinlik tamponu yoktur; görünürlük çoğu zaman çizim sırası ( ve şeffaflık kuralları ) ile çözülür. İki boyutta bu yönetilebilir; üç boyutlu projeksiyon veya iç içe yüzeylerde sıralama maliyeti üssel olarak karmaşıklaşır — klasik «boyayıcı algoritması» ( painter’s algorithm ) sınırları ortaya çıkar.

Bu limit, Canvas’ın «kötü» olduğu anlamına gelmez; ürün gereksinimi gerçekten sürekli derinlik çakışması çözümü istiyorsa WebGL ( veya üst katman motor ) doğal adaydır. Neden WebGL · derinlik bu köprüyü tamamlar — burada tekrar teknik derinlik dersi verilmez.

Kirli dikdörtgen ve katman stratejisi görünürlükle ilişkilidir fakat derinlik yerine kısmi güncelleme eksenindedir — Kirli dikdörtgen başlığıyla çakışmayı önlemek için burada yalnızca «sıra / tampon eksikliği» bağlamı işaretlenir.

Birleştirme kuralları ve öngörülebilirlik sınırı

globalCompositeOperation ve ilişkili kurallar güçlü efektler üretir; çok katmanlı sahneyi bu kurallar üzerinden kurmak, tasarımcının zihninde net olsa bile kodda hızla karmaşıklaşır. Özellikle bir modun bir diğerinin üzerinde beklenmedik sonuç üretmesi, regresyon riskini artırır. WebGL tarafında karşılığı özel shader ve çerçeve tamponları ( framebuffer ) ile daha açıkça mühendislik ister — fakat davranış daha «sözleşmeli» tanımlanabilir.

Çok sayıda süzgeç ve gölge kombinasyonu mobilde darboğaza gider; bu performans limitidir ( bağlam maliyeti ile ilişkili ) — burada ek olarak tasarım öngörülebilirliği ekseni vurgulanır.

Köprü özeti: görünüm diliniz «özel karışım grafı» ise Canvas ile yaşamak mümkündür; dil «standart aydınlatma + materyal parametreleri» ise motor veya WebGL düşünmek daha sürdürülebilir olabilir.

Metin, düzen ve vektör grafik gerçekleri

Canvas üzerinde metin çizmek mümkündür; ancak düzen motorunun ( satır kırma, erişilebilirlik, seçilebilirlik, IME ile yazım ) gücü DOM’un gerisindedir. Yoğun ve sürekli güncellenen metinli arayüzlerde Canvas tek başına sık sık sürdürülebilirlik sorunu çıkarır — bu bir «performans limiti»nden çok ürün mühendisliği limitidir.

SVG ve DOM ile hibrit yaklaşımlar yaygındır; tamamen Canvas içinde çözülmesi gerekiyorsa metin önbake veya atlas düşünülür — görsel yükleme akışı ile bağlantılıdır fakat burada tekrarlanmaz.

Köprü: WebGL dünyasında da metin genelde doku veya özel raster çözümüdür — Canvas limiti «metin magicsız çözülmez» değil; doğru ara katmanı seçmek meseleidir.

Piksel geri okuma ve ana iş parçacığı senkronu

getImageData gibi işlemler GPU tamponundan CPU belleğine veri çekmeyi içerebilir ve ana iş parçacığında beklemeye yol açar — bu «anında mod» ile çelişen maliyetli bir köprüdür. Her karede tam ekran okuma çoğu üründe sürdürülemez. CPU/GPU · geri okuma bölümü aynı düşünceyi bağlam düzeyinde işler.

Bu limit, görüntü işleme veya oyun mantığında «tuvalden örnekle» desenini zorlar; çözüm genelde okumayı seyrekleştirmek, daha küçük bölge seçmek veya WebGL / işçi iş parçacığı hattında veriyi GPU üzerinde tutmaktır. Offscreen Canvas bazen ara tampon olarak yardımcı olur; geri okuma maliyeti doğası gereği kalır.

Güvenli tampon boyutu seçimi için sayıları doğrudan kullanıcı girdisinden almadan önce üst sınıra sıkıştıran küçük bir yardımcı aşağıdadır — gerçek üst sınır tarayıcıya göre değişir; sabit varsayılan bilinçli olarak muhafazakârdır. 

/**
 * İç tampon boyutlarını pozitif tam sayıya ve üst sınıra sıkıştırır (
 * tarayıcı gerçek üst sınırını ayrıca doğrulayın ).
 */
export function clampBackingStoreSize(widthCssPx, heightCssPx, maxSide = 4096) {
  const cap = Math.max(64, Math.floor(Number(maxSide) || 4096));
  const w = Math.min(cap, Math.max(1, Math.floor(Number(widthCssPx) || 1)));
  const h = Math.min(cap, Math.max(1, Math.floor(Number(heightCssPx) || 1)));
  return { width: w, height: h };
}

Çözünürlük, DPR ve uygulama farklarına duyarlılık

Aynı Canvas kodu farklı tarayıcı ve sürücü kombinasyonlarında küçük görsel farklar üretebilir; özellikle alt piksel hizalama, süzgeç ve metin rasterı konularında. Bu «tam deterministik kalem» beklentisi Canvas dünyasında risklidir — özellikle çapraz tarayıcı görsel regresyon testleri gerektiren ürünlerde.

Cihaz piksel oranı ( DPR ) ile iç tampon boyutu politikası yanlış kurulursa bulanıklık veya ağır tampon oluşur — yeniden boyutlandırma mantığı ile uyum zorunludur. Limit burada API’nın kötülüğü değil; ölçüm ve politika eksikliği yüzünden patlayan maliyettir.

Aşağıdaki denetim fonksiyonu yalnızca ürün ekibinin tartışma maddelerini üretir; sahayı otomatik seçmez. DOM veya bağlam açmaz. 

/**
 * Canvas 2D sürtünme noktalarını ürün bayraklarından listeler — kesin karar vermez.
 * @param {Record<string, unknown>} raw
 */
export function auditCanvas2dFriction(raw) {
  const f = raw && typeof raw === 'object' ? raw : {};

  /** @type {string[]} */
  const friction = [];

  if (f.requiresTrue3dVisibility === true) {
    friction.push('Donanım derinlik tamponu olmadan görünürlük yükü');
  }
  if (f.reliesOnFullFrameReadback === true) {
    friction.push('Sık tampon geri okuma');
  }
  if (f.needsPerPixelProgrammableLogic === true) {
    friction.push('Özel piksel programı ihtiyacı (sabit raster modeli dışına çıkış)');
  }
  if (f.crossBrowserPixelIdentical === true) {
    friction.push('Piksel düzeyinde çapraz tarayıcı özdeşlik beklentisi');
  }
  if (typeof f.canvasDrawCallsPerFrame === 'number' && f.canvasDrawCallsPerFrame > 1500) {
    friction.push('Yüksek çizim çağrısı (ölçüme göre yönetilmeli)');
  }

  const score = friction.length;
  return {
    friction,
    score,
    /** İki veya daha fazla madde teknik köprü incelemesi gerektirebilir. */
    recommendArchitectureReview: score >= 2,
  };
}

WebGL köprüsü, tuzaklar ve kontrol listesi

Yukarıdaki limitler birikince köprü mantığı devreye girer: derinlik ve shader kontrolü için WebGL ( veya motor ), metin için DOM katmanı, okuma için GPU üzerinde kalma veya seyrek örnekleme. Tek bir doğru yoktur — ürün ölçütleri ( ekip, zaman çizelgesi, hedef cihaz ) kararı belirler. Neden WebGL? başlığı «ne zaman geçilir?» sorusunu tamamlar.

Tuzaklar: «Canvas yetersiz» diyerek ölçümsüz WebGL’ye atlamak; metin ağırlıklı ürünü tamamen WebGL içinde yeniden icat etmek; geri okuma ihtiyacını WebGL ile de çözülmeden bırakmak. Köprü her zaman çözüm değil — bazen içerik veya tasarım sadeleştirmesi daha ucuzdur.

Bu sayfanın sınırı

WebGL veya WebGPU öğreticisi, Three.js kurulumu ve donanım sürücü düzeyi optimizasyonları burada işlenmez. Odak: Canvas 2D’nin tasarım kaynaklı kenarlarını köprü kararı için dilimize dökmektir.

  • Görünürlük gerçekten sıralama ile mi çözülüyor, derinlik şartsız mı?
  • Geri okuma sıklığı ürün için sürdürülebilir mi?
  • Birleştirme grafiği karmaşıklığı bakım maliyetini taşıyor mu?
  • Metin ve erişilebilirlik gereksinimleri Canvas ile mi DOM ile mi daha iyi?
  • Taşınabilirlik ( DPR / tarayıcı ) test planı var mı?