WBK AI
V.I.P
Flutter’da bir animasyonun ilk çalıştırmada takılıp ikinci çalıştırmada akıcı olması, Skia tabanlı çizimde shader derlemesinin bilinen belirtilerinden biriydi. Widget ağacını sadeleştirmek bu sorunu tek başına çözmüyordu: gecikme, Dart kodundan değil, çizim sırasında hazırlanan GPU programlarından kaynaklanabiliyordu.
Impeller bu sorunun önemli bir kaynağını ortadan kaldırmak için tasarlandı. Ancak “shader derlemesinden kaynaklanan takılmayı önlemek” ile “uygulamada hiç kare kaçırmamak” aynı şey değil. Bu yazıda o ayrımı, shader hazırlama sürecini ve performansı nasıl ölçmek gerektiğini ele alıyoruz.
TL;DR
Shader, GPU’da çalışan küçük bir programdır. Bir şeklin rengi, karışım biçimi veya görsel efektleri için gereken çizim davranışını hesaplayabilir. Skia’nın Flutter’da kullanılan geleneksel GPU çizim yolunda, farklı çizim kombinasyonları için shader’lar çalışma sırasında üretilebilir ve derlenebilirdi. Daha önce hazırlanmamış bir kombinasyon ilk kez kullanıldığında bu iş, karenin tamamlanmasını geciktirebilirdi.
Burada SkSL (Skia Shading Language), Skia’nın kullandığı shader dilidir; doğrudan GPU sürücüsüne verilen evrensel bir makine kodu değildir. Skia, seçilen Metal, Vulkan veya OpenGL backend’ine uygun shader gösterimlerine dönüşümü yönetir. Ardından platformun derleme ve pipeline hazırlama adımları devreye girer.
120 Hz ekranda her yenileme aralığı yaklaşık 8,33 ms, 60 Hz ekranda ise 16,67 ms sürer. Bir karenin kritik çizim işi bu bütçeyi aşarsa kare hedeflenen zamanda sunulamayabilir. Bunlar ekran yenileme aralığından hesaplanan bütçelerdir; belirli bir uygulamadan alınmış benchmark sonuçları değildir.
UI iş parçacığı Dart tarafındaki build, layout ve paint çalışmalarını yürütür. Raster iş parçacığı ise kaydedilen çizim komutlarının GPU backend’i üzerinden işlenmesini koordine eder. İki aşama ardışık kareler üzerinde örtüşerek çalışabilir. Bu nedenle “CPU’da pahalı bir iş var” demek, o işin mutlaka Dart’ın UI iş parçacığında olduğu anlamına gelmez.
Bu ayrım çözümü de değiştirir. Ağ isteğinin kendisi asenkron yapılabilir; her istek için isolate açmak gerekmez. Ağdan gelen büyük bir JSON’u ayrıştırmak gibi CPU yoğun işler için isolate kullanımı değerlendirilebilir. Fakat bu, raster tarafındaki shader hazırlama gecikmesini doğrudan çözmez.
SkSL warmup yaklaşımında uygulama bir eğitim çalıştırmasından geçirilir, karşılaşılan shader’lar kaydedilir ve sonraki açılışlarda önceden hazırlanmaları sağlanırdı.
Bu yöntem yararsız değildi, ancak kapsamı test sırasında gezilen ekranlara ve yakalanan çizim kombinasyonlarına bağlıydı. Atlanan bir akış yeni shader ihtiyacı doğurabilir, kapsamlı warmup ise açılış süresini uzatabilirdi. Aynı platformdaki cihazlarda bile tutarlı sonuç garanti edilemiyordu. Buna karşılık, “bir iPhone’da alınan kayıt başka bir iPhone’da hiçbir işe yaramaz” demek de fazla kesindir.
Her parametre değişimi yeni bir shader anlamına gelmez: bazı değerler aynı programa uniform olarak aktarılabilir. Yeni varyasyon gerekip gerekmediği, çizim işleminin yapısına ve backend’e bağlıdır.
Impeller, Flutter motoruyla birlikte dağıtılan, elle yazılmış ve önceden bilinen bir shader kümesi kullanır. Shader üretimi ve arayüz bilgilerinin çıkarılması (reflection) gibi işler motorun derleme aşamasına taşınır. Motor ayrıca gerekli grafik pipeline’larını çizim sırasında sürpriz iş çıkarmayacak şekilde önceden hazırlamayı hedefler. Flutter’ın mimari belgeleri bu yaklaşımı öngörülebilir performans hedefiyle açıklar.
Kavramsal akış: motor derlemesi, cihazda hazırlık ve kare çizimi ayrı aşamalardır. Görsel bir benchmark değildir; büyütmek için tıklayın.
AOT (ahead-of-time), işin kullanım anından önce yapılmasını anlatır. Buradaki shader hazırlığı, Dart uygulamasının AOT derlemesinden ayrı bir süreçtir. Impeller’ın derleyicisi shader kaynaklarını backend’e uygun biçimlere dönüştürür ve motorla paketler.
Pratik kazanım, çizim sırasında dinamik shader üretimi ve buna bağlı ilk-kullanım sürprizlerini azaltmaktır. Bunu “her backend’de bütün sürücü işlemleri sıfır milisaniyedir” veya “raster thread hiçbir koşulda beklemez” diye okumamak gerekir.
Tessellation, eğri ve yolların çizime uygun geometrik parçalara, çoğunlukla üçgenlere, dönüştürülmesidir. CPU tessellation, GPU tabanlı geometri üretimi ve stencil-then-cover gibi teknikler farklı iş yüklerinde kullanılabilir. Impeller’ın tüm SVG yollarını her platformda compute shader’a taşıdığını söylemek doğru bir genelleme değildir. Seçilen yöntem şekle, backend’e ve motor sürümüne bağlıdır.
Benzer biçimde, birçok mobil GPU çizimi küçük ekran bölgeleri (tile) üzerinden işler. İyi düzenlenen render pass’ler ve uygun olduğunda subpass’ler, ara verilerin çip üzerindeki bellekte tutulmasına yardımcı olabilir. Gereksiz ana bellek yazma-okumalarını azaltmak performans ve enerji kullanımı açısından faydalıdır. Ancak bütün renk, stencil ve derinlik verilerinin her sahnede son ana kadar tile belleğinde kaldığı garanti edilemez.
Arka plan bulanıklığı, büyük ara render hedefleri, çok sayıda üst üste çizim veya yüksek çözünürlüklü görseller hâlâ pahalı olabilir. Impeller kullanmak, her sahnede daha az pil tüketimi veya daha düşük bellek kullanımı garantisi vermez.
“2026’da destekleniyor” tek başına yeterli bilgi değil. Aşağıdaki durum, Flutter’ın 3.47 belgeleri ve sürüm matrisi esas alınarak özetlenmiştir. Başka bir sürüm kullanıyorsanız ilgili sürümün belgelerini kontrol edin.
Skia ile karşılaştırmayı da bu bağlamda yapmak gerekir. Impeller, Flutter’ın öngörülebilir kare süreleri ihtiyacına göre tasarlanmıştır; bu, genel amaçlı Skia’nın her kullanımda mimari olarak daha kötü olduğu anlamına gelmez. Impeller ekibi de kendi FAQ belgesinde genel bir “Skia’dan daha iyi” iddiasından özellikle kaçınır.
DevOpen’ın Subara ve Dondurma projeleri somut test senaryoları kurmak için kullanılabilir. Ancak bu yazıda bu uygulamalara ait doğrulanabilir ham ölçüm paylaşmıyoruz; dolayısıyla cihaz ve trace olmadan “10 kat hızlı” veya “sabit 120 FPS” sonucu vermiyoruz.
Editör notu: Önceki sürümde bulunan performans tablosu, bu inceleme kapsamında ham trace ve test koşullarıyla doğrulanamadığı için kaldırıldı. Yerine tahmini benchmark eklenmedi.
p99 ne söyler? 99. yüzdelik değerin 120 Hz için 8,33 ms altında olması yararlı bir göstergedir. Fakat en yavaş yaklaşık %1’lik bölümde bütçe aşımı bulunabilir; ayrıca ölçtüğünüz aşama toplam kare sunumunu tek başına açıklamayabilir. Bu nedenle p99’dan “hiç kare kaçmadı” sonucu çıkmaz.
Impeller’ın kazanımı, shader hazırlığını uygulama geliştiricisinin test sırasında bütün ekranları gezerek çözmeye çalıştığı bir sorundan çıkarıp motorun tasarımına taşımasıdır. Özellikle ilk-kullanım takılmaları açısından bu önemli bir değişikliktir.
Yine de ekranda takılma gördüğümüzde ilk sorumuz “Impeller açık mı?” ile sınırlı kalmamalı. Hangi iş parçacığı bütçeyi aştı, hangi efekt pahalı, gecikme sürücüde mi yoksa uygulama kodunda mı? Yanıtı trace verir. Web tarafındaki farklı çizim yoluyla ilgileniyorsanız Flutter WebAssembly ve CanvasKit yazısına da bakabilirsiniz; native sonuçları web’e doğrudan taşımamak gerekir.
Teknik kontrol: 23 Ekim 2026. Platform özeti Flutter 3.47 belgelerine dayanır. Aşağıdaki yaşayan belgeler daha sonra değişebilir; motorun main dalındaki mimari açıklamalar sürüm garantisi olarak okunmamalıdır.
Impeller bu sorunun önemli bir kaynağını ortadan kaldırmak için tasarlandı. Ancak “shader derlemesinden kaynaklanan takılmayı önlemek” ile “uygulamada hiç kare kaçırmamak” aynı şey değil. Bu yazıda o ayrımı, shader hazırlama sürecini ve performansı nasıl ölçmek gerektiğini ele alıyoruz.
TL;DR
- Impeller, önceden bilinen sınırlı bir shader kümesini motor derlenirken hazırlar; Skia’nın çizim sırasında üretebildiği shader varyasyonlarına farklı bir yaklaşım getirir.
- MSL bir shader dili, SPIR-V ise bir ara gösterimdir. İkisi de her cihaz için hazır nihai GPU makine koduyla eş anlamlı değildir.
- Önceden hazırlanan shader’lar, pahalı Dart işlemlerini, ağır efektleri veya bütün sürücü sorunlarını ortadan kaldırmaz.
- Platform bilgileri aşağıda Flutter 3.47 için verilmiştir. Sonuçları değerlendirirken kendi SDK sürümünüzü ve kullanılan backend’i kaydedin.
Skia’da ilk çalıştırma neden takılabiliyordu?
Shader, GPU’da çalışan küçük bir programdır. Bir şeklin rengi, karışım biçimi veya görsel efektleri için gereken çizim davranışını hesaplayabilir. Skia’nın Flutter’da kullanılan geleneksel GPU çizim yolunda, farklı çizim kombinasyonları için shader’lar çalışma sırasında üretilebilir ve derlenebilirdi. Daha önce hazırlanmamış bir kombinasyon ilk kez kullanıldığında bu iş, karenin tamamlanmasını geciktirebilirdi.
Burada SkSL (Skia Shading Language), Skia’nın kullandığı shader dilidir; doğrudan GPU sürücüsüne verilen evrensel bir makine kodu değildir. Skia, seçilen Metal, Vulkan veya OpenGL backend’ine uygun shader gösterimlerine dönüşümü yönetir. Ardından platformun derleme ve pipeline hazırlama adımları devreye girer.
120 Hz ekranda her yenileme aralığı yaklaşık 8,33 ms, 60 Hz ekranda ise 16,67 ms sürer. Bir karenin kritik çizim işi bu bütçeyi aşarsa kare hedeflenen zamanda sunulamayabilir. Bunlar ekran yenileme aralığından hesaplanan bütçelerdir; belirli bir uygulamadan alınmış benchmark sonuçları değildir.
UI thread ile raster thread aynı işi yapmaz
UI iş parçacığı Dart tarafındaki build, layout ve paint çalışmalarını yürütür. Raster iş parçacığı ise kaydedilen çizim komutlarının GPU backend’i üzerinden işlenmesini koordine eder. İki aşama ardışık kareler üzerinde örtüşerek çalışabilir. Bu nedenle “CPU’da pahalı bir iş var” demek, o işin mutlaka Dart’ın UI iş parçacığında olduğu anlamına gelmez.
Bu ayrım çözümü de değiştirir. Ağ isteğinin kendisi asenkron yapılabilir; her istek için isolate açmak gerekmez. Ağdan gelen büyük bir JSON’u ayrıştırmak gibi CPU yoğun işler için isolate kullanımı değerlendirilebilir. Fakat bu, raster tarafındaki shader hazırlama gecikmesini doğrudan çözmez.
SkSL warmup neyi çözüyordu, nerede sınırlıydı?
SkSL warmup yaklaşımında uygulama bir eğitim çalıştırmasından geçirilir, karşılaşılan shader’lar kaydedilir ve sonraki açılışlarda önceden hazırlanmaları sağlanırdı.
.sksl.json kayıtları ve --bundle-sksl-path seçeneği bu tarihsel iş akışının parçalarıydı; güncel bir Impeller uygulaması için başlangıç önerisi değiller.Bu yöntem yararsız değildi, ancak kapsamı test sırasında gezilen ekranlara ve yakalanan çizim kombinasyonlarına bağlıydı. Atlanan bir akış yeni shader ihtiyacı doğurabilir, kapsamlı warmup ise açılış süresini uzatabilirdi. Aynı platformdaki cihazlarda bile tutarlı sonuç garanti edilemiyordu. Buna karşılık, “bir iPhone’da alınan kayıt başka bir iPhone’da hiçbir işe yaramaz” demek de fazla kesindir.
Her parametre değişimi yeni bir shader anlamına gelmez: bazı değerler aynı programa uniform olarak aktarılabilir. Yeni varyasyon gerekip gerekmediği, çizim işleminin yapısına ve backend’e bağlıdır.
Impeller neyi farklı yapıyor?
Impeller, Flutter motoruyla birlikte dağıtılan, elle yazılmış ve önceden bilinen bir shader kümesi kullanır. Shader üretimi ve arayüz bilgilerinin çıkarılması (reflection) gibi işler motorun derleme aşamasına taşınır. Motor ayrıca gerekli grafik pipeline’larını çizim sırasında sürpriz iş çıkarmayacak şekilde önceden hazırlamayı hedefler. Flutter’ın mimari belgeleri bu yaklaşımı öngörülebilir performans hedefiyle açıklar.
Kavramsal akış: motor derlemesi, cihazda hazırlık ve kare çizimi ayrı aşamalardır. Görsel bir benchmark değildir; büyütmek için tıklayın.
AOT shader, Dart AOT ve GPU makine kodu
AOT (ahead-of-time), işin kullanım anından önce yapılmasını anlatır. Buradaki shader hazırlığı, Dart uygulamasının AOT derlemesinden ayrı bir süreçtir. Impeller’ın derleyicisi shader kaynaklarını backend’e uygun biçimlere dönüştürür ve motorla paketler.
- Metal Shading Language (MSL): Metal için kullanılan shader dilidir. Apple derleme araçlarıyla Metal kütüphanelerine dönüştürülmesi, MSL kaynak metninin kendisinden ayrı bir adımdır.
- SPIR-V: Vulkan’ın tüketebildiği bir ara gösterimdir; her Adreno veya Mali GPU için hazır nihai makine kodu değildir.
- Pipeline State Object (PSO): Shader’ların yanı sıra çizim durumunu da tanımlayan pipeline nesnesidir. Nesnenin oluşturulması ve sürücü tarafındaki hazırlık, shader kaynağını üretmekle aynı iş değildir.
Pratik kazanım, çizim sırasında dinamik shader üretimi ve buna bağlı ilk-kullanım sürprizlerini azaltmaktır. Bunu “her backend’de bütün sürücü işlemleri sıfır milisaniyedir” veya “raster thread hiçbir koşulda beklemez” diye okumamak gerekir.
Tessellation ve GPU belleği: önemli, ama sihirli değil
Tessellation, eğri ve yolların çizime uygun geometrik parçalara, çoğunlukla üçgenlere, dönüştürülmesidir. CPU tessellation, GPU tabanlı geometri üretimi ve stencil-then-cover gibi teknikler farklı iş yüklerinde kullanılabilir. Impeller’ın tüm SVG yollarını her platformda compute shader’a taşıdığını söylemek doğru bir genelleme değildir. Seçilen yöntem şekle, backend’e ve motor sürümüne bağlıdır.
Benzer biçimde, birçok mobil GPU çizimi küçük ekran bölgeleri (tile) üzerinden işler. İyi düzenlenen render pass’ler ve uygun olduğunda subpass’ler, ara verilerin çip üzerindeki bellekte tutulmasına yardımcı olabilir. Gereksiz ana bellek yazma-okumalarını azaltmak performans ve enerji kullanımı açısından faydalıdır. Ancak bütün renk, stencil ve derinlik verilerinin her sahnede son ana kadar tile belleğinde kaldığı garanti edilemez.
Arka plan bulanıklığı, büyük ara render hedefleri, çok sayıda üst üste çizim veya yüksek çözünürlüklü görseller hâlâ pahalı olabilir. Impeller kullanmak, her sahnede daha az pil tüketimi veya daha düşük bellek kullanımı garantisi vermez.
Flutter 3.47’de platform desteği
“2026’da destekleniyor” tek başına yeterli bilgi değil. Aşağıdaki durum, Flutter’ın 3.47 belgeleri ve sürüm matrisi esas alınarak özetlenmiştir. Başka bir sürüm kullanıyorsanız ilgili sürümün belgelerini kontrol edin.
- iOS: Impeller desteklenen tek çizim motorudur; eski Skia GPU renderer’ına geçiş seçeneği kaldırılmıştır. Bu, Flutter’dan bütün Skia bileşenlerinin çıkarıldığı anlamına gelmez: metin yerleşimi ve görüntü codec’leri gibi alanlarda Skia bileşenleri kullanılmaya devam eder.
- Android: Impeller, Android 10 / API 29 ve üzerindeki uygun Vulkan cihazlarında varsayılandır. Vulkan sürümü, gerekli uzantılar ve cihaz kısıtları da önemlidir. Vulkan kullanılamadığında belgelerde belirtilen eski OpenGL çizim yoluna geri dönüş yapılabilir; bunun her sürümde Impeller’ın OpenGL backend’i olduğunu varsaymayın.
- macOS, Windows ve Linux: 3.47 matrisi Impeller’ı bu platformlarda varsayılan olarak listeler; önceki sürümlerin durumu farklıdır. Bundan belirli bir Direct3D 12 backend’inin üretim desteğine ilişkin sonuç çıkarmamak gerekir.
- Web: Native platformlardaki Impeller geçişi web’e otomatik olarak uygulanmaz. Flutter web, CanvasKit ve skwasm gibi Skia tabanlı renderer’lar kullanır.
Skia ile karşılaştırmayı da bu bağlamda yapmak gerekir. Impeller, Flutter’ın öngörülebilir kare süreleri ihtiyacına göre tasarlanmıştır; bu, genel amaçlı Skia’nın her kullanımda mimari olarak daha kötü olduğu anlamına gelmez. Impeller ekibi de kendi FAQ belgesinde genel bir “Skia’dan daha iyi” iddiasından özellikle kaçınır.
Kendi uygulamanızda farkı nasıl ölçersiniz?
DevOpen’ın Subara ve Dondurma projeleri somut test senaryoları kurmak için kullanılabilir. Ancak bu yazıda bu uygulamalara ait doğrulanabilir ham ölçüm paylaşmıyoruz; dolayısıyla cihaz ve trace olmadan “10 kat hızlı” veya “sabit 120 FPS” sonucu vermiyoruz.
Editör notu: Önceki sürümde bulunan performans tablosu, bu inceleme kapsamında ham trace ve test koşullarıyla doğrulanamadığı için kaldırıldı. Yerine tahmini benchmark eklenmedi.
- Ortamı kaydedin: Flutter sürümü, cihaz modeli, GPU, işletim sistemi, ekran yenileme hızı ve etkin renderer/backend.
- Profile modunda başlayın: DevTools Performance görünümüyle UI ve raster sürelerini ayrı inceleyin. Debug ölçümlerini release performansı gibi sunmayın. Gerekirse release çalıştırması ve platformun GPU araçlarıyla ek doğrulama yapın.
- Tekrarlanabilir senaryo seçin: Aynı ekran geçişi, aynı kaydırma rotası ve aynı veri kümesi. Ağ, görsel çözme ve platform view işlemlerini kontrol edin.
- İlk çalıştırmayı ayırın: Cold-start/ilk-kullanım ve ısınmış tekrarları ayrı raporlayın. Süreç yeniden başlatıldığında hangi önbelleklerin korunduğunu da belirtin.
- Dağılıma bakın: Medyan, p95 ve p99 kare sürelerini; kare bütçesini aşan kare sayısını; örnek sayısını ve tekrar sayısını paylaşın. UI, raster ve GPU sürelerini birbirinin yerine kullanmayın.
- Karşılaştırmanın sınırını yazın: Skia/Impeller A/B testi yalnızca her iki renderer’ı destekleyen sürüm ve platformlarda mümkündür. iOS’ta güncel motorla Skia’ya dönülebileceğini varsaymayın. Ham DevTools trace’ini ve test kodunu rapora ekleyin.
p99 ne söyler? 99. yüzdelik değerin 120 Hz için 8,33 ms altında olması yararlı bir göstergedir. Fakat en yavaş yaklaşık %1’lik bölümde bütçe aşımı bulunabilir; ayrıca ölçtüğünüz aşama toplam kare sunumunu tek başına açıklamayabilir. Bu nedenle p99’dan “hiç kare kaçmadı” sonucu çıkmaz.
Sonuç: daha öngörülebilir çizim, yine gerekli profil analizi
Impeller’ın kazanımı, shader hazırlığını uygulama geliştiricisinin test sırasında bütün ekranları gezerek çözmeye çalıştığı bir sorundan çıkarıp motorun tasarımına taşımasıdır. Özellikle ilk-kullanım takılmaları açısından bu önemli bir değişikliktir.
Yine de ekranda takılma gördüğümüzde ilk sorumuz “Impeller açık mı?” ile sınırlı kalmamalı. Hangi iş parçacığı bütçeyi aştı, hangi efekt pahalı, gecikme sürücüde mi yoksa uygulama kodunda mı? Yanıtı trace verir. Web tarafındaki farklı çizim yoluyla ilgileniyorsanız Flutter WebAssembly ve CanvasKit yazısına da bakabilirsiniz; native sonuçları web’e doğrudan taşımamak gerekir.
Kaynaklar ve kapsam
Teknik kontrol: 23 Ekim 2026. Platform özeti Flutter 3.47 belgelerine dayanır. Aşağıdaki yaşayan belgeler daha sonra değişebilir; motorun main dalındaki mimari açıklamalar sürüm garantisi olarak okunmamalıdır.
- Flutter: Impeller rendering engine — amaçlar, varsayılanlar ve fallback davranışı.
- Impeller README — Flutter 3.47.0 — shader hazırlama akışı ve sürüm matrisi.
- Impeller FAQ — warmup geçmişi, Skia ile farklar ve kullanılan Skia bileşenleri.
- Android backend seçimi — Vulkan gereksinimleri ve sürüme bağlı fallback notları.
- DevTools Performance görünümü ve çizim performansını iyileştirme — ölçüm ve teşhis.