Achieving smooth frame rates with a Metal display link

At a glance

Project structure

Source bundle/
├── Shared/
│   ├── GameViewController.mm
│   ├── AssetLoader.mm
│   ├── Shaders.metal
│   ├── Renderer.mm
│   ├── WindowSceneDelegate.m
│   └── ShaderTypes.h
├── iOS/
│   └── main.m
├── macOS/
│   └── main.m
└── tvOS/
    └── main.m

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; GameView is the principal feature coordinator.
• GPU-specific logic stays in Metal shader files; shared headers bridge host/shader layouts where present.
• The tree above is intentionally pruned to composition, resource, and shader files.

Overall architecture

flowchart LR
    N1["GameViewController"]
    N2["GameView display link"]
    N3["Renderer"]
    N4["Metal submission"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Shared/GameView.m:165 — display-link creation, pacing policy, and callback ownership

    _displayLink = [[CAMetalDisplayLink alloc] initWithMetalLayer:metalLayer];
    _displayLink.preferredFrameRateRange = CAFrameRateRangeMake(120.0, 120.0, 120.0);
    _displayLink.preferredFrameLatency = 2;
    _displayLink.paused = NO;
    // Assign the delegate to receive the display update callback.
    _displayLink.delegate = self;

Interpretation

This is the dominant control/data path: platform code composes GameView; that object controls display-link pacing; GPU-visible work ends in per-frame Metal submission. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    GameView *-- CAMetalDisplayLink : _displayLink

Ownership evidence

Shared/GameView.m:165 — GameView creates, configures, and stores _displayLink

    _displayLink = [[CAMetalDisplayLink alloc] initWithMetalLayer:metalLayer];
    _displayLink.preferredFrameRateRange = CAFrameRateRangeMake(120.0, 120.0, 120.0);
    _displayLink.preferredFrameLatency = 2;
    _displayLink.paused = NO;
    // Assign the delegate to receive the display update callback.
    _displayLink.delegate = self;

Class and protocol design

A local protocol/conformance boundary is present, so protocol-oriented collaboration is claimed only for that seam.

Access control

This sample does not use Swift private, fileprivate, or public for its native boundary. Objective-C/Objective-C++ use header versus implementation placement, C++ uses access specifiers/linkage, Python uses module conventions, and Metal entry points cross a compiled-library boundary; these are not Swift access levels.

Logic ownership and placement

Shader boundary reference

Shared/Shaders.metal:22 — representative GPU entry/helper

[[ vertex ]]

Design patterns

Naming conventions

• Role suffixes make ownership visible: GameViewController, Renderer, GameView, AppDelegate, GameViewDelegate, WindowSceneDelegate.
• Method names describe setup or encoding actions: application, applicationShouldTerminateAfterLastWindowClosed, drawableResize, renderTo, initCommon, resizeDrawable, stopRenderLoop.
• Shader entry points use stage/operation names: vertexShader, fragmentShader.
• Names favor concrete domain roles and target-local types; no broad public library namespace is introduced.

Architecture takeaways

• Keep GameViewController focused on composition; GameView is the owner of display-link pacing.
• Treat per-frame Metal submission as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is AssetLoader → _textureLoader; broader exclusive ownership is not inferred.
• Access-control rationale follows concrete language boundaries rather than translating every header or shader symbol into Swift terms.

Source map

• Official Apple documentation