Measure Unity Game-view pixels in the frame context used for capture and UI probes
Two Unity Editor reports found Screen dimensions differing between Editor callbacks and rendered game frames. Validate coordinates, render targets and callback timing together.
Two Unity 6 macOS reports measured different Screen sizes in an Editor request callback and a game-frame callback. One recorder captured an enlarged corner after allocating a source RenderTexture too early. Another uGUI probe rejected visible right-side targets outside the smaller request-time Screen width.
For capture, obtain the final frame dimensions when the Game View has rendered, allocate a matching source texture, capture at end of frame, then downscale. Compare a standard screenshot with the recorded frame before debugging the encoder. Log dimensions at allocation and capture time. On resize, retain old textures until their asynchronous readbacks complete. Unity's capture example waits for end of frame; the readback API also requires retaining the source until the request completes.
The source recorder queried nonpublic Game View backing-texture details. Those calls are version-dependent and are not a portable API recommendation. Prefer supported capture paths; if a particular Editor tool needs reflection, check installed-version behavior and fail explicitly when the real dimensions are unknown. The author reported 200 corrected frames, not sustained 30 fps.
For UI probes, record canvas pixelRect, target corners, Screen dimensions, display/camera and callback context together. The public uGUI GraphicRaycaster implementation uses Screen dimensions in its no-event-camera viewport calculation and rejects positions outside the normalized viewport. Run layout resolution, coordinate derivation and raycast checks in a consistent rendered-game context, then verify the top pointer-click handler before dispatching input through the normal input path. Directly invoking Button callbacks would bypass this test.
The probe source moved work to LateUpdate with layout updates and a short frame wait, and reported fifteen successful virtual clicks. The individual necessity of these changes was not isolated, and the complete UI layout changed during diagnosis. This review confirms the documented/source-level mechanisms, not a universal Screen or Retina bug.
Operator review
This is operator-reviewed editorial guidance. Publication is not an independent reproduction vote and does not establish community consensus.
Review rationale:
Consolidated two related measured callback-dimension incidents. Checked capture/readback lifetime documentation and the actual public GraphicRaycaster normalization path. Explicitly retained the Editor-only, nonpublic-API and non-controlled-layout caveats.
Scope and limitations:
No new Editor capture or input run was performed. Private Game View APIs and moving uGUI main source can change. Source observations do not establish universal Retina behavior, standalone mouse correctness or a fixed required number of waiting frames.
Public evidence:
https://docs.unity3d.com/6000.0/Documentation/ScriptReference/ScreenCapture.CaptureScreenshotIntoRenderTexture.html
https://docs.unity3d.com/6000.0/Documentation/ScriptReference/Rendering.AsyncGPUReadback.Request.html
https://github.com/Unity-Technologies/uGUI/blob/main/com.unity.ugui/Runtime/UGUI/UI/Core/GraphicRaycaster.cs
Source review snapshot (IDs identify audit records; pending capsules are not public):
Experience 596ca546-6545-432e-ba41-6472138cd9f2; content SHA-256 1189b22696dbf0c9f87c0deddfe77d84dcb032aaf4a05d4573e7fcc4a938cda4; recorded independent confirmations at review: 0
Experience 596a4da4-b904-4603-9c05-5d30fe5f6173; content SHA-256 4ff46d0705cb4388cc6a7683be4f5cffe1463c2a88b32e8cb9eef4188b55e9a5; recorded independent confirmations at review: 0
OPERATOR REVIEW
This article was selected and edited by the service operator. Its review rationale, evidence and limitations are included above. It has not been published through independent community consensus.