Tarayıcı GIF editörü: dosya boyutu değil bellek sınırı önemli

Bir GIF editörü geliştirirken karşılaşılan pratik bir sorun: dosya boyutu ve bellek kullanımı arasında beklenmedik bir fark vardır. Küçük görünen bir GIF, tarayıcıda işlenirken muazzam miktarda RAM tüketebilir.

Düşün ki 1000×1000 piksel boyutunda 100 karellik bir animasyonun var. Bu 100 milyon piksel demek. Her piksel RGBA formatında 4 bayt tutarsa, tüm karelerin çözülmüş halini bellekte tutmak 400 MB gerektirir. Sıkıştırılmış GIF dosyası belki 5-10 MB'dır, ama bellek maliyeti çok daha yüksektir.

VisualFormat gibi tarayıcı tabanlı GIF araçları bu sorunu nasıl çözer? Dosyayı indirdikten sonra değil, indirmeden önce kontrol eder. GIF bloklarını tarar, boyutları, kare sayısını ve toplam piksel miktarını kontrol eder. Sonra karar verir: bu dosya işlenebilir mi?

Reklam · TEST
AdSense Test ReklamıYazı arası (gönderi içi) · Yazı arası

Önemli bir detay: her kare tam bir resim değildir. Bazı karelerin yalnızca canvas'ın bir bölümü güncellenmiş olabilir. Şeffaflık (transparency) ve yerel palet (local palette) kullanımı bellek hesaplamalarını karmaşıklaştırır. Bu yüzden güvenilir araçlar maksimum sınırlar koyar: 20 MB dosya, 500 kare, 4096 piksel genişlik/yükseklik, 40 milyon toplam piksel gibi.

Bu sınırlar gardrail'dir, garantı değil. Her cihaz farklı kapasite sunur. Mobil tarayıcı masaüstünde çalışan dosyayı işleyemeyebilir.

Alın mesaj: dosya boyutu ve bellek tüketimi bağımsız metriktir. Sıkıştırma oranı yüksek olsa bile, çözülen veri belleği doldurup uygulamayı dondurabileceğini bilmek gerekir.

Reklam · TEST
AdSense Test ReklamıGönderi altı · Görüntülü
konu hakkında tepkinizi verebilirsiniz