feat: increase camera reel gallery capacity from 500 to 1000 photos - #10127
decentraland-bot wants to merge 1 commit into
Conversation
Bumps GRID_POOL_MAX_SIZE to match the planned backend MAX_IMAGES_PER_USER increase. The gallery uses infinite-scroll pagination (100 items/page) so memory impact is minimal — textures load on demand and are viewport-culled. Closes #10126 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
🚦 CI StatusWindows and Mac built successfully in Unity Cloud.
Warnings not reduced: 11910 => 11910 — remove at least 1 warning to merge. Warnings/errors in files changed by this PR (27)Lint run · took 26m 22s All Unity tests passed ✅
Tests time sums the test cases; Job time is the job's wall clock including checkout, licensing and asset import. Slowest tests
Full report: run summary · results + editor logs: editmode · playmode 🏁 Bare-metal benchmark finished — run #35075504820. Full reportPR #10127, run #35075504820 Overall: ✅ no significant changes Builds: Windows change, Windows baseline, macOS change, macOS baseline How to read this table
Apple M1
Intel Core i5
On demand — comment |
|
Slack notification sent to #explorer-ext-contributions for external review. |
decentraland-bot
left a comment
There was a problem hiding this comment.
Review — PR #10127: feat: increase camera reel gallery capacity from 500 to 1000 photos
STEP 1 — Scope
Files changed: 1 (Explorer/Assets/DCL/InWorldCamera/CameraReelGallery/CameraReelGalleryController.cs)
Diff: +1 −1 — a single constant value change.
The GRID_POOL_MAX_SIZE constant is consumed once, passed to ReelGalleryPoolManager at construction as the upper bound for the month-grid object pool. THUMBNAIL_POOL_MAX_SIZE (10 000) is unchanged and already far above the new cap.
Subsystem docs and surrounding files reviewed: CameraReelGalleryController manages the gallery UI with infinite-scroll pagination (page size 100, triggered within 12 slots of the bottom). Textures are viewport-culled (nulled off-screen, restored from cache on re-entry). The pool ceiling is never pre-allocated — it only limits how many returned objects the pool will retain.
Deterministic lint pre-flight: scripts/lint/custom-rules.sh does not exist on this branch; the enforcement layer has not landed here. Machine-held rules checked by hand — none fire on this diff.
STEP 2 — Root-cause check ✅
Problem: The backend MAX_IMAGES_PER_USER is being raised from 500 to 1000 (separate ops task). The client-side grid-element pool ceiling must match so the pool can retain enough month-grid objects when a user scrolls through a larger gallery.
Assessment: This is a direct config alignment to a planned backend change — not a symptom-level fix. The constant is the correct place to express this limit. PASS.
STEP 3 — Design & integration ✅
No new units introduced — no system, plugin, manager, service, controller, or stateful helper. The change is a numeric constant on an existing class. No owner search required.
Teardown/consumption trace: No new subscriptions, callbacks, connections, buffers, or measurements. N/A.
PASS.
STEP 4 — Member audit
No public properties or accessors added or changed. N/A.
STEP 5 — Line-level review
Single constant change at line 62. Checked against all blocking-issue categories (R1–R24):
| Category | Result |
|---|---|
| R1 hot-path allocations | No new allocations |
| R2 LINQ in hot paths | No LINQ added |
| R3 class refs in structs | N/A |
| R4 ECS lifecycle | N/A — not an ECS system |
| R5 Entity by-ref | N/A |
| R6 Acquire/release symmetry | No new acquires |
| R7 Nullability honesty | No nullability changes |
| R8 Root cause vs symptom | Config alignment, not a fix |
| R9 Logging | No logging changes |
| R10 Catch-scope | No catch changes |
| R11 Cancellation/async | No async changes |
| R12 Single-impl abstractions | No new abstractions |
| R13 Reuse/centralize | N/A |
| R14 Contract honesty | N/A |
| R15 Dead weight | N/A |
| R16–R17 Naming | Constant name accurately describes its role |
| R18 Magic numbers | Value is a named constant ✓ |
| R19 File hygiene | N/A |
| R20 .NET idiom cluster | N/A |
| R21 MVC conventions | N/A |
| R22 Tests | Config ceiling change — no new behaviour to test; backend still serves 500 until the ops task lands |
| R23 AI comments | No new comments in the diff |
| R24 Scope discipline | Single file, single concern ✓ |
No blocking issues found.
Sub-agent review (security · architecture · simplicity)
Three parallel review agents (security audit, architecture review, simplicity pass) analyzed the diff. All returned no findings — the change is a bounded, proportional constant increase with no security, architectural, or over-engineering concerns.
STEP 8 — Non-blocking warnings
None. Main scene not modified.
Merge gates
- R25 — Outstanding comments: 0 unresolved review threads (only bot CI-status comments present). ✅
- R26 — QA sign-off: Awaiting QA. PR does not carry
no QA needed.
REVIEW_RESULT: PASS ✅
COMPLEXITY: SIMPLE
COMPLEXITY_REASON: Single constant value change in a gallery UI controller — no ECS, async, lifecycle, or architectural surface touched.
QA_REQUIRED: YES
Reviewed by Jarvis 🤖 · Requested via GitHub
Summary
GRID_POOL_MAX_SIZEfrom 500 → 1000 inCameraReelGalleryController.csto match the planned backendMAX_IMAGES_PER_USER=1000env-var updateTHUMBNAIL_POOL_MAX_SIZEis already 10000 — no change needed thereWhy this is safe
camera-reel-servicetest suite already usesmax_images_per_user: 1000intests/common/mod.rs$0.006/month per user who fills the new cap ($6/month per 1,000 capped users)Backend change (separate ops task)
Update
MAX_IMAGES_PER_USER=1000in thecamera-reel-servicedeployment config. No code change or rebuild needed.Documentation (follow-up)
Update "up to 500 photos" in:
decentraland/documentation→content/player/FAQs/decentraland-101.mdline 121decentraland/docs→player/faqs/decentraland-101.mdline 148Closes #10126
🤖 Generated with Claude Code