SkiaSharp 4.0 Preview 1: 10 Yıl Sonra Büyük Atılım Geldi
Açık konuşayım, SkiaSharp benim için biraz nostaljik bir kütüphane. Xamarin.Forms zamanlarında, 2019’du sanırım, bir bankacılık projesinde özelleştirilmiş bir grafik bileşeni yazmam gerekmişti; müşteri PDF dışa aktarımı, ekranda canlı çizim ve aynı görüntünün sunucu tarafında render edilmesini istiyordu, üç farklı platformda tek bir görsel sonuç beklenince de insan ister istemez “bunu nasıl toparlarız” diye düşünüyor. Mantıklı değil mi? O zamanlar SkiaSharp olmasaydı, valla bilemiyorum nasıl çıkardık işin altından.
Şimdi 10 yıl sonra SkiaSharp 4.0 Preview 1 çıktı. Ve bu, sıradan bir minör sürüm değil. İki buçuk yıllık Skia upstream güncellemesini bir anda getiriyor; üstüne Microsoft.NET ekibi ve Uno Platform’un ortak bakımına geçiyor, yanı işin altyapısı baya değişiyor. Evet.
Bu yazıda önce neyin değiştiğine bakacağız, sonra benim Türkiye’deki müşteri profillerinde bunu nasıl konumlandırdığımı anlatacağım; çünkü kağıt üstünde güzel duran şeyler sahada bazen başka türlü davranıyor. Bir de — geçişte dikkat etmeniz gereken birkaç tuzak var, onları da paylaşayım.
SkiaSharp Neden Önemli? Kısa Bir Hatırlatma
Şöyle başlayayım:.NET tarafında çapraz platform 2D grafik işine girdiğinizde, eliniz pek de rahat olmuyor. System.Drawing var, evet; ama o daha çok Windows kafasında kalıyor ve modern senaryolarda, mesela Linux server üstünde PDF üretirken, bir anda insanın başına küçük ama can sıkıcı işler açabiliyor. Microsoft da System.Drawing.Common‘ı non-Windows tarafta destek dışı bıraktı zaten.
SkiaSharp işe Google’ın Chrome, Android ve Flutter’da kullandığı Skia engine‘in.NET binding’i (kendi tecrübem). Neden önemli bu? Yanı öyle boş bir çizim kütüphanesi değil; milyarlarca cihazda dönen, baya sahada pişmiş bir motorun üstüne oturuyorsunuz..NET MAUI’nın Graphics altyapısı, Uno Platform’un render katmanı, WinUI 3’ün bazı parçaları — hepsi ya SkiaSharp üstüne kurulu ya da onunla yan yana çalışıyor.
Hmm, bunu nasıl anlatsamdı…
Şöyle söyleyeyim, Burada mesele sadece “güzel çizim yapmak” falan değil aslında. Modern.NET cross-platform UI hikâyesinin omurgasında bu var diyebilirim. Hatta biraz iddialı konuşayım, sız bunu kullanmasanız bile etkisini başka yerlerde görüyorsunuz.
Evet.
Preview 1’de Ne Geldi?
İşin garibi, Lafı uzatmadan başlıkları dökeyim, sonra tek tek neyin ne olduğuna bakalım:
- Skia milestone 147 — yanı 28 upstream sürüm bir arada (bu kritik)
- Mipmap sharpening varsayılan olarak açık
- Otomatik EXIF rotation desteği
- Büyük görüntülerin GPU texture limitlerine otomatik tile’lanması
- Rec.709, HLG, PQ transfer fonksiyonları endüstri standardına uygun hâle getirildi (bu kritik)
- Modern compiler güvenlik mitigasyonları tüm platformlarda aktif (bence en önemlisi)
- Bundle edilmiş native bağımlılıklar güvenlik yamaları ile güncel — ciddi fark yaratıyor
Mipmap Sharpening — Detayı Olan Fark
Bunu biraz açmak lazım. Yıllardır SkiaSharp ile thumbnail üreten herkes bilir, küçültülmüş görseller bazen fazla yumuşak kalırdı; hatta 2000×2000 bir ürün fotoğrafını 200×200’e indirince, özellikle e-ticaret tarafında, görüntü resmen sünger gibi görünürdü.
4.0 ile mipmap sharpening varsayılan geliyor. Yanı küçülen görseller daha net dürüyor, daha az dağılıyor; manuel ayar yapmak isteyen yine eski davranışa dönebiliyor ama açık konuşayım, default hali baya iş görüyor.
EXIF Rotation — Sonunda!
Bunu yıllardır bekliyordum, cidden. Mobil uygulamada kullanıcı fotoğrafı yükleyince — hele iPhone tarafında — o görselin portrait mı landscape mi olduğunu anlamak için EXIF metadata’sına bakmanız gerekiyordu; eskiden SkiaSharp bunu kendi kendine yapmıyordu, sız de SKCodecOrigin okuyup matrix transformasyonu ile uğraşıyordunuz.
Şimdi codec EXIF rotation’ı otomatik uyguluyor (ciddiyim). Geçen hafta bir e-belge yönetim projesinde tam bu dertle boğuşuyorduk; taranmış belgelerin yarısı yan dönmüş geliyordu, hani gözünüz bir an ekrana kayıyor. “bu niye böyle” diyorsunuz — kendi adıma konuşayım — ya, işte öyle bir durumdu. 4.0 çıkınca o kodu silip geçeceğiz.
İşte tam da bu noktada devreye giriyor.
Büyük Görüntü Tile’lama
Vallahi, GPU texture limitleri var, kaçış yok. Mesela Android cihazların çoğunda maksimum 4096×4096 ya da 8192×8192 sınırı görüyorsunuz; daha büyük bir bitmap’i GPU’ya yüklemeye kalkınca ya hata alırsınız ya da görüntü siyaha düşer, şey gibi olur: her şey tamam sanarsınız. E peki, sonuç ne öldü? Ekranda hiçbir şey yoktur.
4.0 artık bunu otomatik tile’lıyor. Yanı 12000×9000’lık bir tıbbi görüntüleme dosyasını canvas’a verdiğinizde kendi içinde parçalıyor; sağlık sektöründe çalışan biri buna şaşırmaz bile. DICOM benzeri yüksek çözünürlüklü işler orada gündelik hayatın parçası zaten.
“İki buçuk yıllık upstream’i bir anda almak, kod değiştirmeden ciddi kalite ve performans iyileştirmesi getiriyor. Ama bu aynı zamanda — bazı edge case’lerde davranış değişikliği demek. Önce staging’de test edin, sonra prod.”
Uno Platform Co-Maintainer Öldü — Bu Ne Anlama Geliyor?
Bence bu sürümdeki en önemli haber teknik taraftan çok governance tarafında dürüyor. SkiaSharp’ı şimdiye kadar büyük ölçüde Matthew Leibowitz tek başına götürüyordu; topluluk katkısı vardı, evet, ama iş bir yerde tıkanıyordu, hele yeni Skia milestone’larına geçiş bazen aylarca uzuyordu.
Kısa konuştum. Ama mesele orada bitmiyor.
Garip gelecek ama, Uno Platform şirketi artık resmî olarak co-maintainer rolüne geçiyor. Bunun pratik karşılığı şu: Skia upstream’den gelen güncellemeler daha hızlı SkiaSharp’a inebilecek, Android binding’leri, AOT iyileştirmeleri ve WASM tarafı da daha rahat akacak; Uno zaten bu alanlarda epey derin çalışıyor, yanı laf olsun diye girilmiş bir ortaklık gibi durmuyor.
Şey, burada küçük bir parantez açayım. Bazı ekipler “bana ne, ben Uno kullanmıyorum” diyebilir, ama olay o kadar düz değil; çünkü böyle bir bakım modeli oturunca paketlerin arkası biraz daha sağlam geliyor, beklenmedik kırılmalar azalıyor, güncelleme yaparken insanın içi daha az sıkılıyor.
Evet, doğru duydunuz.
Türkiye’deki.NET ortamı açısından bakınca tablo biraz farklı (bizzat test ettim). Uno Platform’un buradaki adopsiyonu şimdilik sınırlı; çoğu kurumsal müşterimde MAUI tercih ediliyor. Ama açık konuşayım, Uno’nun SkiaSharp’a katkısı dolaylı da olsa MAUI kullanıcılarına da yarayacak,. Uno kullanmıyor olsanız bile bu işbirliğinden sız de pay alıyorsunuz.
Peki, peki neden? Çünkü altyapı işi böyle bir şey işte.
Türkiye’deki Şirketler Açısından Ne Anlama Geliyor?
Şimdi dürüst olayım, bu kısım biraz kritik. Bir bankacılık ya da sigortacılık müşterisine “yeni preview çıktı, hadi geçelim” demek pek gerçekçi değil, çünkü stabilite işi burada şaka kaldırmıyor; ama bazı senaryolarda bu sürüm baya iş görüyor, hatta beklemediğim kadar fark yaratabiliyor.
Senaryo 1: PDF / Belge Üretimi
Bak şimdi, Bir telekom müşterisinde aylık fatura PDF’i üretiyoruz — milyonlarca adet, az buz değil. SkiaSharp ile bir PDF kütüphanesini yan yana kullanıyoruz; eski sürümde Linux container’larda render farkları görüyorduk, özellikle font hinting tarafında can sıkıyordu. 4.0’daki Skia milestone 147 bu konuda ciddi düzeltmeler getirmiş, açık konuşayım bizim tarafta bunun karşılığı doğrudan zaman kazancı öldü.
Senaryo 2: Mobil İmza ve Doküman Tarayıcı
Bir sigorta şirketinde poliçe imza ekranı yapmıştık — kullanıcı parmağıyla imza atıyor, biz de bunu canvas üstünde pürüzsüz çizgiyle render edip sunucuya gönderiyoruz. İlk bakışta basit gibi dürüyor, ama işin içine EXIF rotation otomatikleşmesi ve mipmap sharpening girince görüntü kalitesi gözle görülür biçimde toparlanıyor; hani şu “ufak dokunuş ama etkisi var” dediğimiz türden.
İşte tam da bu noktada devreye giriyor.
Evet.
Senaryo 3: Sunucu Tarafı Görsel İşleme
Container Apps" data-glossary-term="Azure Container Apps">Azure Container Apps’te çalışan bir image processing servisi düşünün. Eskiden ImageSharp mı SkiaSharp mı diye arada kalırdık; sonra bir bakıyorsun konu sadece performans değil, güvenlik sertleştirmeleri. Büyük görüntü tile’laması da devreye giriyor (yanı tablo biraz değişiyor). Bu yüzden sunucu tarafı senaryolarda SkiaSharp artık daha rahat tercih ediliyor diyebilirim.
Şimdi, peki neden?
Enterprise vs Startup: Hangi Senaryoda Ne Yapmalı?
| Durum | Küçük Ekip / Startup | Kurumsal / Enterprise |
|---|---|---|
| Yeni proje başlıyor | Direkt 4.0 Preview ile başla, geri bildirım ver. Hızlısın zaten. | 3.x stable kullan, GA’yı bekle. Açık konuşayım, burada acele etmek pek iyi fikir değil; çünkü entegrasyonlar, güvenlik onayları ve ekip alışkanlıkları derken iş bir anda uzuyor. |
| Mevcut prod uygulama | Test branch’inde dene, sorun yoksa geç. Basit gibi dürüyor ama bazen küçük bir paket farkı bile geceyi bozabiliyor. | QA’da 2-3 ay paralel test, regression suite zorunlu. Evet, uzun sürüyor; ama canlı ortamda sürpriz çıkınca kimse “keşke” demek istemiyor. |
| Sunucu render workload | Hızla preview’a geç, güvenlik avantajı önemli. Bu tarafta risk biraz daha tolere ediliyor, çünkü dönüş hızı kritik. | GA bekle ama şimdiden POC çalış. Hani tam geçiş yapmadan önce kokusunu almak lazım, yoksa sonra performans tarafında can sıkıcı şeyler çıkabiliyor. |
| MAUI mobil uygulama | MAUI sürümüyle uyumu kontrol et, geç. Şey, burada en çok kaçan detay bağımlılık zinciri oluyor. | MAUI bağımlılığını kontrol et, koordineli geçiş yap. Yukarıda bahsettiğim o olay var ya, işte bu senaryoda ekipler arası senkron gerçekten fark yaratıyor; backend başka sürümde kalırsa mobil taraf boşuna yoruluyor. |
İtiraf edeyim, Peki neden?
Küçük ekipte hız daha baskın oluyor; kurumsalda işe dengeyi kaçırmamak gerekiyor. Bak şimdi, aynı teknoloji iki yerde bambaşka davranıyor gibi görünür (bir yerde “deneyelim gitsin” dersin, öbür yerde işe değişiklik bile ticket açtırır), o yüzden karar verirken sadece sürüm numarasına bakmak yetmiyor.
Araya gireyim: Açık konuşayım, preview sürümler bazen baya iş görüyor; özellikle yeni projede veya kontrollü test ortamında elini çabuk tutuyorsan güzel akıyor. Ama prod sistemde işler öyle yürümüyor mu? Hayır. Orada biraz temkinli olmak daha mantıklı geliyor.
E sonra?
Vallahi, Eğer takım küçükse ve rollback planın netse, erken geçiş çoğu zaman mantıklı olabiliyor. Ama enterprise tarafta ben genelde önce POC isterim; çünkü teoride sorunsuz görünen şeyler pratikte loglara saçma sapan hatalar bırakabiliyor ve sonra kimse tam olarak nerede koptuğunu anlayamıyor.
İnanın, Neyse uzatmayayım, mesele şu: hızlı hareket etmek her zaman doğru değil, yavaş olmak da her zaman iyi değil. İkisinin ortasını bulmak lazım; yanı senaryoya göre karar vermek en temiz yol oluyor.
Geçişte Dikkat Edilecek Noktalar
Preview’a geçerken birkaç noktayı atlamamak lazım. Şu an sürüm 4.0 Preview 1, yanı üretim tarafı için ben olsam hemen koşamam; Microsoft da zaten bunu öyle sunmuyor. Deneme yapmak, bir şeyleri yoklamak ve geri bildirım bırakmak için işe gayet uygun dürüyor (evet, doğru duydunuz)
Ben kendi local’ımde küçük bir test projesi kurdum. NuGet’ten paketi çektim, elimdeki eski bir SkiaSharp kodunu ayağa kaldırdım, hani ilk bakışta “tamam bu iş olur” dedirtti; ama SKImage.FromBitmap çağrısında ufak ama can sıkıcı bir fark gördüm — encoding sırasında color profile davranışı değişmiş gibi geldi, %100 emin değilim ama üstüne daha derin bakacağım.
Açıkçası, İlk adımda şunları yapmanızı öneririm:
- Mevcut SkiaSharp kullanımınızın bir envanterini çıkarın — hangi API’ler var, hangi platformlarda dönüyorlar, hangisi hayatı hangisi değil, bunu netleştirin
- Görsel regresyon testi yazın (eski sürümle yeni sürümün aynı çıktıyı verdiğini kontrol eden snapshot test), çünkü bazen kod çalışır ama görüntü hafif kayar, işte o nokta insanı uğraştırır (bu kritik)
- Preview 1’i ayrı bir branch’te deneyin — ciddi fark yaratıyor
- Issue açın — özellikle davranış değişikliği gördüğünüzde mono/SkiaSharp repo’sunda; sessiz kalınca sorun büyüyebiliyor, açık konuşayım
Maliyet Açısından Düşünmek
SkiaSharp ücretsiz, open source, güzel (ciddiyim). Ama işin asıl faturası lisansa değil, ekibin harcadığı zamana çıkıyor. Bir kurumsal projede SkiaSharp majör version geçişi yaparken ben olsam 2-4 haftayı test. Regresyon için kenara koyarım; cross-platform render’a kritik bağımlılığınız varsa, açık konuşayım, bu süre biraz daha uzuyor.
Bunu Azure tarafına çekince tablo netleşiyor. Bir App Service Plan ya da Container App’in render performansında %5-10 iyileşme yakalarsanız, ayda 100.000+ istek alan bir servis için bu baya fark ettiriyor; hani küçük gibi dürüyor. TL hesabı yapınca insanın kaşı kalkıyor. Skia 147’nın getirdiği performans iyileştirmeleri tam da burada iş görüyor.
İşte tam da bu noktada devreye giriyor.
Alternatifler: Bütçe Kısıtlıysa veya Riski Sevmiyorsanız
SkiaSharp’a şu an geçmek istemiyorsanız, ya da “ben biraz daha temkinli gideyim” diyorsanız, başka yollar da var.
- ImageSharp — Sunucu tarafında görsel işleme için baya iş görüyor, %100 managed code çalışıyor, lisans tarafı artık kurumsal kullanımda ücretli ama açık konuşayım, hâlâ makul kalıyor
- Microsoft.Maui.Graphics — MAUI içinde basit 2D çizimlerde yeterli olabiliyor, SkiaSharp kadar geniş değil ama bağımlılığı hafif tutması güzel bir artı
- QuestPDF — Eğer derdiniz sadece PDF üretmekse, SkiaSharp yerine bakılabilecek seçeneklerden biri bu
Şunu söyleyeyim, Ama işin aslı şu: cross-platform 2D rendering lazımsa, SkiaSharp hâlâ önde gidiyor. Hatta bu sürümle fark biraz daha açılmış gibi dürüyor.
Peki neden?
Çünkü elinizdeki senaryo genelde tek bir şey olmuyor; bazen PDF, bazen ekran çizimi, bazen de sunucuda hızlı görsel manipülasyonu gerekiyor. Tam o noktada SkiaSharp’ın esnekliği, şey, diğer seçeneklerin önüne geçiyor. Neden önemli bu? Yine de her projeye körlemesine bunu koymak da doğru değil; bütçe dar işe ya da risk almak istemiyorsanız önce ihtiyaç listesini netleştirin.
Açık konuşayım, Tam da öyle.
İlgili Yazılarım
Bu konuyla bağlantılı olarak .NET 10 ile WebAssembly Hızlanınca Copilot Studio’da Neler Değişti? yazımda WASM tarafındaki değişikliklere değinmiştim — SkiaSharp’ın WASM render performansı da işin içinde, (ciddiyim). Öyle kenarda köşede duran bir detay değil.
Bir de.NET ekosistemindeki başka paket güncellemeleri için vcpkg Nisan 2026: Kilitler, Hız ve Küçük Ama Kritik Dokunuşlar yazımda native dependency yönetimi tarafına bakmıştım. SkiaSharp’ın native bağımlılıklarını anlamak istiyorsanız, açık konuşayım, orası baya iş görüyor.
Sıkça Sorulan Sorular
SkiaSharp 4.0 Preview 1’i prod’da kullanabilir mıyım?
Şöyle söyleyeyim, Kısa cevap: kullanma. Microsoft ve maintainer’lar zaten önermiyor, hani preview sürümler test ve geri bildirım için çıkıyor. Kurumsal projelerde aslında 3.x stable sürümünde kalmak çok daha mantıklı, GA gelene kadar beklemeye değer. Ama açıkçası küçük ekipler için preview üzerinde POC yapmak fena bir fikir değil, bence gayet makul.
Mevcut SkiaSharp 3.x kodum 4.0 ile çalışacak mı?
Büyük ölçüde çalışıyor, ama bazı davranış değişiklikleri var. Yanı özellikle mipmap sharpening, EXIF rotation ve color transfer fonksiyonlarındaki düzeltmeler yüzünden bazı edge case’lerde görsel çıktınız değişebiliyor. Tecrübeme göre snapshot tabanlı görsel regresyon testleri burada gerçekten hayat kurtarıyor, genelde çalıştırın.
.NET MAUI projem SkiaSharp 4.0’a ne zaman geçecek?
Aslında, MAUI’nın SkiaSharp bağımlılığı kademeli güncelleniyor, hani net bir tarih henüz yok. Büyük ihtimalle SkiaSharp 4.0 GA çıktıktan sonra bir MAUI minör sürümüyle geliyor. Aslında.NET 10 sonrasında bir noktada bekleyebilirsiniz.
Uno Platform’un co-maintainer olması bana ne kazandırır?
Şunu söyleyeyim, Uno kullanmasanız bile bu sizi etkiliyor, mesela kütüphane artık çok daha aktif sürdürülüyor ve Skia upstream’den daha hızlı güncellemeler alıyorsunuz. Tahmin eder mısınız? Bence en somut faydası şu: bug fix ve yeni feature’lar artık çok daha çabuk geliyor.
Sunucu tarafı render için SkiaSharp güvenli mi?
4.0 ile birlikte modern compiler güvenlik mitigasyonları artık tüm platformlarda aktif. Native dependency’ler de güvenlik yamalarıyla güncel tutuluyor (yanlış duymadınız). Açıkçası sunucu tarafı kullanım için 4.0 GA, 3.x’e kıyasla çok daha güvenli bir tercih olacak.
Peki neden?
Kaynaklar ve İleri Okuma
Welcome to SkiaSharp 4.0 Preview 1 —.NET Blog
Şöyle ki, Skia Graphics Engine Resmî Sitesi
Uno Platform — SkiaSharp Co-Maintainer
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder