imajviewer/docs/rapor-pan-kilitleme-nuks.md

Rapor — Efekt Uygulanmış Görselde Pan Sırasında Kilitlenme (Nüks)

Tarih: 2026-08-06 Durum: Analiz — hipotezler hazır, açık sorular kullanıcı yanıtını bekliyor

1. Semptom (yeni bildirim)

• Donma sorunu yeniden ortaya çıktı — bu kez "diğer bilgisayarda" (VM değilse ortamı bilinmiyor; önceki testler Xubuntu VM + llvmpipe idi).
• Tetikleyici farklı: önceki nüksler efekt sürüklemesi sırasında idi (contrast/saturation/brightness/rotate drag). Şimdi efekt uygulanmış durumda (değerler sabit) iken PAN yaparken kilitlenme.
• "Olmadık zamanlarda" — rastgele zamanlarda, her pan'da değil.

2. Önceki Teşhisler ve Çözümler (kayıt özeti)

Tarih	Teşhis	Çözüm	Durum
03 Ağu	Kuyruk birikmesi: pointer event hızı (100-250/sn) > llvmpipe kare hızı → setState her event'te → UI thread %100, 30-60sn donma	_markRenderDirty() frame-throttle (kare başına max 1 rebuild) + ResizeImage (viewport×2) + provider memoize + cache 16/256MB + galeri geçişinde imageCache.clear()	Uygulandı, ölçüldü (raster ort ~15ms, max ~50ms, kuyruk birikmesi yok)
06 Ağu	İlk kullanım shader derlemesi (B1): process başına soğuk Skia/GL cache; ilk ColorFiltered/Transform kullanımı 15sn-1dk derleme	Shader warmup: açılışta gizli Opacity(0) katmanla filtre + rotate shader'larını derlet	Uygulandı (release build + kurulum 06 Ağu)

2b. Kullanıcı Yanıtları (2026-08-06, ikinci bildirim)

• Ortam: gerçek makine — Mesa Intel(R) HD Graphics 3000 (SNB GT2) (Sandy Bridge iGPU, 2011). mesa i965 driver GLSL'i LLVM ile CPU'da derler → karmaşık shader varyantları 30sn'ye çıkabilir. 12GB RAM, son sürüm kurulu.
• Test sonuçları (kullanıcı):
  • Resim büyükse (dosya ~1MB+) oluyor; küçük görselde olmuyor.
  • Fill modda olmuyor, fit modda oluyor.
  • İlk açılışta fit moda geçip rotate edilirse oluyor — tek seferlik, sonra tekrar değil (kullanıcı "sanırım" ile ifade etti, teyit beklenecek).
• Bu bilgiler Aday F'yi doğruluyor: warmup 1x1 gizli katmanda yapılıyor, gerçek kullanımın (büyük doku + fit BoxFit.contain + rotate + ColorFiltered) shader varyantı warmup'ta derlenmiyor → ilk gerçek kullanımda 30sn derleme.
• Aday A (ColorFiltered CPU filtrelemesi) ve C (bellek) elendi — GPU var, RAM bol.
• EKLENTİ (kullanıcı kurcalayınca): Fill modda da oluyor; "biraz zorlayınca aynı resimde tekrar oldu" — yani tek seferlik DEĞİL. Bu Aday F'yi (ilk kullanım derlemesi, cache'li kalır) zayıflatıyor; varyant sayısı fazlaysa her yeni kombinasyon yeni derleme olabilir (aşağıda Aday H/I).

Her iki çözüm de mevcut kodda aktif: image_canvas.dart → _markRenderDirty, provider memoize (_cachedProvider), _buildWarmupLayer().

3. Yeni Analiz — Neden "Efekt + Pan" Kilitlenir?

Pan akışı: _onPanUpdate → _tx/_ty += delta → _clamp() → _markRenderDirty().

Aday A — ColorFiltered her pan frame'inde tüm görseli CPU'da filtreliyor ⭐

• Efekt aktifken (hasFilter == true) her rebuild'te ColorFiltered → Image tüm görsel 5x4 matrisle filtrelenir. Pan'da translate değişir → her frame'de yeniden boyama + filtreleme.
• 4000×3000 görsel ≈ 12M piksel; llvmpipe'ta filtre + ölçekleme + translate ≈ 20-60ms/kare. FPS 15-50'ye düşer → "takılma" hissi.
• _markRenderDirty kuyruk birikmesini engeller ama kare başına maliyet yüksekse düşük FPS kalıcı olur. Büyük görsel + zayıf makinede bu "kilitlenme" gibi algılanabilir.
• Rotate aktifse (pan serbest, _clamp erken return) Transform + ColorFiltered birlikte — en ağır kombinasyon.

Aday B — _clamp() pan event hızında findRenderObject() çağırıyor ⭐

• _onPanUpdate her event'te _clamp() çağırır; fit modda _clamp() içinde _imageKey.currentContext?.findRenderObject() (satır 77) pointer hızında (throttle'ın DIŞINDA) render tree sorgusu yapar. Pan event'leri 100-250/sn → gereksiz layout/tree traversal yükü. Kilitlenme üretmez ama takılmayı artırır.

Aday C — Bellek/GC baskısı ("olmadık zamanlarda" rastgeleliğin en iyi adayı)

• Rastgele kilitlenme imzası GC/swap'e işaret eder. "Diğer bilgisayar"da RAM azsa (8GB altı) veya başka işler varsa: büyük görsel decode + 256MB cache + pan sırasında GC pause → kısa ama algılanabilir donmalar.
• Pan sırasında yeni decode yok (memoize) → cache baskısı düşük; ama makine belleği dar ise OS seviyesinde swap thrashing olabilir.

Aday D — Eski binary / farklı ortam ("diğer bilgisayar")

• "Diğer bilgisayarda" kurulu sürüm bilinmiyor. Eski .deb (warmup/memoize öncesi) kuruluysa sorun zaten açıklanır. Ayrıca o makinede donanım GPU'su VARSA teşhis tamamen değişir (llvmpipe değil) — ColorFiltered donanımda ucuzdur, o zaman aday C veya farklı bir sebep aranır.

Aday E — Pan sırasında yeni frame kuyruğu (zayıf)

• scheduleFrameCallback kare başına 1 callback garanti eder; kare süresi uzarsa FPS düşer ama kuyruk birikmez (03 Ağu ölçümü). Kilitlenme üretmez.

Aday F — Warmup varyant eksikliği: 1x1 katman gerçek kullanımı derlemiyor ⭐⭐⭐

• Warmup (_buildWarmupLayer) 1x1 boyutunda gizli katmanla filtre + rotate shader'larını derletiyor. Skia/GL'de shader varyantları doku boyutu, sampling modu, filtre kalitesi gibi parametrelere göre ayrı derlenir.
• Gerçek kullanımda büyük görsel (4000x3000) + FilterQuality.high + BoxFit.cover/contain + ColorFiltered + pan/zoom Transform — bu kombinasyonun shader'ı 1x1 warmup'ta derlenenle aynı varyant olmayabilir → ilk gerçek kullanımda derleme yine olur → 30sn kilitlenme.
• "Efekt uygulanmışken pan yaparken" tetikleyicisi: pan/zoom + ColorFiltered birlikte ilk kez kullanıldığında varyant derlenir; sonrası cache'li → "olmadık zamanlarda" ve "her pan'da değil" imzası birebir uyuyor.
• GPU'da shader derleme süresi genelde ms seviyesindedir; zayıf/iç ekran kartı + mesa/LLVM backend ile 30sn'ye çıkabilir. "İyi kötü ekran kartı" ifadesi bu olasılığı güçlendiriyor.
• Warmup'ın gerçek boyutla yapılması gerekir: gizli katman 1x1 yerine mevcut görselin boyutunda (veya viewport boyutunda) olmalı; ayrıca pan/zoom Transform'u da warmup'a dahil edilmeli.

Aday G — Gerçek GPU driver / doku sınırı

• Zayıf GPU'da büyük doku (12MP RGBA ≈ 48MB) + ColorFiltered → driver'da aşırı yavaş path veya GL sync beklemesi. glxinfo -B renderer string'i kritik (NVIDIA nouveau / AMD radeon / Intel / llvmpipe?).

Aday H — Skia varyant cache dolması / her kombinasyon yeni derleme ⭐⭐

• "Aynı resimde tekrar oldu" → tek seferlik derleme değil. Skia'da her farklı kombinasyon (zoom seviyesi × rotate açısı × efekt değeri × fit/fill × filtre kalitesi) farklı shader varyantı üretebilir; varyant cache'i sınırlıysa (LRU) eski varyant atılır → aynı kombinasyon tekrar kullanılınca YENİDEN derlenir → 30sn. "Zorlayınca" = çok varyant üretmek = cache'i doldurmak = tekrar derleme.
• Bu, "ilk kullanımda" + "sonra tekrar" imzasını birlikte açıklayan hipotez.

Aday I — Intel HD 3000 GL sync / doku upload darboğazı ⭐⭐

• Sandy Bridge iGPU paylaşımlı bellek kullanır; büyük doku upload + ColorFiltered
  • Transform her frame'de GL sync bekleyebilir. _markRenderDirty throttle frame üretimini sınırlar ama raster thread yavaş kalırsa UI thread frame kuyruğunu tüketemez → 30sn'lik görünür donma (olaylar işlenir, görsel gecikir — önceki raporlardaki imza).
• Doku boyutuna duyarlılık (1MB+ görsel) + fill/fit farkı (BoxFit.cover kırpar → daha küçük etkin doku; contain → tam doku işlenir) bu hipotezle uyumlu.
• Intel HD 3000'de LIBGL_ALWAYS_SOFTWARE=1 (llvmpipe) ile karşılaştırma testi ayırt edici: GL sync sorunu ise software'de farklı davranır.

4. Hipotez Önceliklendirme

Aday	Açıkladığı	Gücü
A (ColorFiltered her frame)	Efekt+pan takılması, "kilitlenme" hissi	⭐⭐ (efekt açıkken kaçınılmaz maliyet; azaltılabilir)
B (_clamp findRenderObject)	Ek pan yükü	⭐ (kolay düzeltilir)
C (bellek/GC)	"Olmadık zamanlarda" rastgelelik	⭐⭐ (makine belleği bilinmiyor)
D (ortam/eski binary)	Tamamen farklı kök	⭐ (önce doğrulanmalı)

5. Önerilen Çözüm Yolları (rapor onayı sonrası)

Seçenek 1 — Pan sırasında filtre maliyetini azalt (Aday A)

• Efekt aktifken pan/zoom sırasında FilterQuality.high → FilterQuality.medium (görsel kalite farkı minimal, llvmpipe yükü düşer) — tek satır.
• Pan sırasında cacheWidth'i düşürme (memoize zaten sabit tutuyor) — gerek yok.
• Alternatif: pan sırasında geçici düşük çözünürlük önizlemesi (mevcut görseli küçük boyutta filtrele) — karmaşık, önce basit yol denenir.

Seçenek 2 — _clamp() içindeki findRenderObject yükünü azalt (Aday B)

• _imageKey.currentContext?.findRenderObject() yalnızca fit modunda lazım; pan'da _vpSize değişmediği sürece tekrar sorgulamaya gerek yok — _clamp'in render sorgusunu her pan event'inde değil, sadece layout değişince yap. (Dikkatli: rotate varken _clamp zaten erken return ediyor; fit modunda kilitlenme riski yok.)

Seçenek 3 — Ortam doğrulaması (Aday D) — rapor öncesi şart

• "Diğer bilgisayar"da: glxinfo -B | grep -i renderer (llvmpipe mi GPU mu), free -h, kurulu sürüm (.deb tarihi / imajviewer --version yoksa binary timestamp). Ayrıca aynı görselle bu VM'de tekrar dener misin — nüks VM'de de mi, sadece diğer makinede mi?

6. Kalan Açık Sorular

1. "Diğer bilgisayar" hangisi — başka VM mi, gerçek makine mi? Donanım GPU'su var mı (glxinfo -B çıktısı)?
2. O makinede kurulu sürüm: son .deb (2026-08-06 sonrası) mi, yoksa eski mi?
3. Kilitlenme süresi ne kadar — 1-2sn mi, 10sn+ mı, yoksa "kapatmak zorunda kaldım" mı?
4. Hangi efekt uygulanmışken pan yapıyorsun — contrast mi, rotate mi (rotate en ağırı)?
5. Görsel boyutu ne — büyük fotoğraf mı (4000px+), küçük ekran görüntüsü mü?
6. Aynı görselle bu VM'de (llvmpipe) pan dener misin — nüks VM'de de oluyor mu?

7. Ölçüm Planı (onaylanırsa)

Skill'deki references/llvmpipe-perf-measurement.md akışı: geçici addTimingsCallback (FRAME build/raster süreleri) + pidstat CPU. Ölçüm sırasında kullanıcı elle pan yapar ("sen aç ben yaparım"). Enstrümantasyon geçicidir ve sonrası temizlenir. VM'de ölçüm yapılabilir; "diğer bilgisayar"da enstrümantasyonlu build kurmak gerekir (kullanıcı onayı şart).

8. Sonuç

İki önceki çözüm (throttle + warmup) doğru teşhislere dayanıyordu ve ilk iki donma imzasını çözdü. Yeni imza farklı: efekt SABİT iken pan. En güçlü açıklama Aday A (ColorFiltered'in her pan frame'inde tam görseli CPU'da filtrelemesi) — özellikle büyük görsel + zayıf makinede "kilitlenme" hissi yaratır. Rastgelelik için Aday C (bellek/GC) ve Aday D (ortam) doğrulanmalı. Kullanıcı yanıtları gelince rapor güncellenir ve çözüm yolları netleşir.

9. Kapanış Notu (2026-08-06)

Kullanıcı donma sırasında top -b -d 1 ölçümü başlattıktan sonra nüks olmadı (ne denediyse kilitlenme/takılma görülmedi). Nüks koşulları belirsiz; konu bu raporla askıda bırakıldı — kullanıcı talep ederse yeniden açılır. Olası ipucu: ölçüm sırasında sistem yükü değişince davranış değişti (Aday I — GL sync/GPU yükü ile ilişkili olabilir; kesin teşhis yapılmadı).