fix: hero artwork rung mismatch between the load key and the memory cache - #95
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
OpenNOW benchmark results
Full JSON: Updated in place on every benchmark run for this PR. |
…rk-rung # Conflicts: # View/Catalog/CatalogContentViews.swift # View/Catalog/CatalogHeroImageViews.swift
The marquee hero's CDN width and decode rung now come from one constant, so the launch prefetch,
the rotation prewarm and the hero view all ask the cache for the same entry. The view previously
inherited the cache's 3840 default while both prefetches warmed 1920, and whichever won the race
set the hero's decode for the session.
CatalogHeroRemoteImagetakes a requiredmaxPixelSizeand logs the rung and decoded byte count it got. Does not revert the deliberate catalog trades
recorded in NEC-39 (eager home
VStack,CatalogContentViewat.opacity(0), hero source-byteretention, lazy-across/eager-down rails).
Closes NEC-58