[Prestaties][P1] Foto's worden in preview, presentator en beamer op bronresolutie (tot 4096 px) gedecodeerd

brenno commented

2026-10-28 16:31:37 +00:00

Owner

Symptoom

Presentaties met veel (telefoon)foto's gebruiken veel geheugen en haperen bij het wisselen van dia, vooral met presentator- en beamervenster tegelijk open. Op laptops met gedeeld videogeheugen (veel Windows 10-machines) valt dat het eerst op.

Oorzaak

cappedFileImage (lib/utils/image_limits.dart:195) decodeert "at native resolution within kMaxImageDecodeDimension" — tot 4096 px per as, ongeacht hoe groot de afbeelding op het scherm staat. Alleen de diastrook en het overzichtsraster zetten een lagere grens (decodeMaxEdge: 512, slide_thumbnail.dart:466, preview_panel_overview_cards.dart:413). De preview, de presentator (huidige én volgende dia), de schermvullende weergave en het beamervenster decoderen op bronresolutie.

Rekenvoorbeeld: een 24 MP-foto (6000×4000) wordt 4096×2731 × 4 bytes ≈ 45 MB per oppervlak. Het beamervenster is een aparte Flutter-engine met een eigen beeldcache, dus die decodeert opnieuw. De standaard imageCache is 100 MB per engine: twee of drie van zulke foto's verdringen elkaar, en bij elke diawissel wordt opnieuw van schijf gelezen en gedecodeerd.

Voorgestelde oplossing

Laat elk oppervlak een decodegrens zetten die past bij zijn weergavegrootte: LayoutBuilder-breedte × devicePixelRatio, naar boven afgerond op een vaste trede (1024 / 2048 / 4096) zodat de cache-sleutels stabiel blijven. Het mechanisme bestaat al (SlidePreviewScope.decodeMaxEdge); het wordt nu alleen door de strook gebruikt.
Export rastert op 1920×1080 (slide_rasterizer.dart), dus daar volstaat de trede 2048 ook — scheelt bij grote fotodecks fors in exportgeheugen en -tijd.
Overweeg daarna imageCache.maximumSizeBytes per engine bewust te kiezen (nu de Flutter-standaard), op basis van een meting.

Wat overeind moet blijven

Scherpe weergave op 4K/Retina in schermvullende presentatie (de trede volgt de echte pixeldichtheid); geanimeerde GIF's blijven animeren (de huidige reden voor "native resolution").

Toets

Widgettest: preview op 800 logische px bij DPR 2 vraagt een decode ≤2048 px aan (assert op de TargetImageSize van een nep-codec); presentatie op 1920 px bij DPR 1 → ≤2048.

Onderdeel van de prestatie- en stabiliteitsinspectie van 28-10-2026 (EPIC #2637).

## Symptoom Presentaties met veel (telefoon)foto's gebruiken veel geheugen en haperen bij het wisselen van dia, vooral met presentator- en beamervenster tegelijk open. Op laptops met gedeeld videogeheugen (veel Windows 10-machines) valt dat het eerst op. ## Oorzaak `cappedFileImage` (`lib/utils/image_limits.dart:195`) decodeert "at native resolution within `kMaxImageDecodeDimension`" — tot 4096 px per as, ongeacht hoe groot de afbeelding op het scherm staat. Alleen de diastrook en het overzichtsraster zetten een lagere grens (`decodeMaxEdge: 512`, `slide_thumbnail.dart:466`, `preview_panel_overview_cards.dart:413`). De preview, de presentator (huidige én volgende dia), de schermvullende weergave en het beamervenster decoderen op bronresolutie. Rekenvoorbeeld: een 24 MP-foto (6000×4000) wordt 4096×2731 × 4 bytes ≈ **45 MB** per oppervlak. Het beamervenster is een aparte Flutter-engine met een eigen beeldcache, dus die decodeert opnieuw. De standaard `imageCache` is 100 MB per engine: twee of drie van zulke foto's verdringen elkaar, en bij elke diawissel wordt opnieuw van schijf gelezen en gedecodeerd. ## Voorgestelde oplossing - Laat **elk** oppervlak een decodegrens zetten die past bij zijn weergavegrootte: `LayoutBuilder`-breedte × `devicePixelRatio`, naar boven afgerond op een vaste trede (1024 / 2048 / 4096) zodat de cache-sleutels stabiel blijven. Het mechanisme bestaat al (`SlidePreviewScope.decodeMaxEdge`); het wordt nu alleen door de strook gebruikt. - Export rastert op 1920×1080 (`slide_rasterizer.dart`), dus daar volstaat de trede 2048 ook — scheelt bij grote fotodecks fors in exportgeheugen en -tijd. - Overweeg daarna `imageCache.maximumSizeBytes` per engine bewust te kiezen (nu de Flutter-standaard), op basis van een meting. ## Wat overeind moet blijven Scherpe weergave op 4K/Retina in schermvullende presentatie (de trede volgt de echte pixeldichtheid); geanimeerde GIF's blijven animeren (de huidige reden voor "native resolution"). ## Toets Widgettest: preview op 800 logische px bij DPR 2 vraagt een decode ≤2048 px aan (assert op de `TargetImageSize` van een nep-codec); presentatie op 1920 px bij DPR 1 → ≤2048. Onderdeel van de prestatie- en stabiliteitsinspectie van 28-10-2026 (EPIC #2637).

brenno added the

enhancement

label

2026-10-28 16:31:37 +00:00

brenno referenced this issue

2026-10-28 16:32:34 +00:00

[EPIC] Prestatie- en stabiliteitsinspectie 28-10-2026: traag bij groot, start niet, loopt vast #2637

brenno added the

in-progress

label

2026-10-29 00:00:17 +00:00

brenno commented

2026-10-29 06:09:04 +00:00

Author

Owner

Opgepakt. Tak: fix/prestatie-2635-2621-2622-2625. Verwachte reikwijdte: decodegrens per oppervlak via SlidePreviewScope.decodeMaxEdge (preview, presentator, beamer, export). imageCache.maximumSizeBytes blijft buiten deze tak.

brenno referenced this issue from a commit

2026-10-29 08:20:37 +00:00

fix: decodeer foto's op de grootte van het vak (#2625)

brenno referenced this issue from a pull request that will close it,

2026-10-29 08:20:57 +00:00

fix: houd typen, memo's, fotodecode en het AI-lampje vlot (#2635 #2622 #2621 #2625) #2658

brenno referenced this issue from a commit

2026-10-29 08:29:41 +00:00

Merge pull request 'fix: houd typen, memo's, fotodecode en het AI-lampje vlot (#2635 #2622 #2621 #2625)' (#2658) from fix/prestatie-2635-2621-2622-2625 into main

brenno closed this issue

2026-10-29 08:29:42 +00:00

brenno referenced this issue from a commit