Implementing order-independent transparency with image blocks
At a glance
| Item | Summary |
|---|---|
| Purpose | Draw overlapping, transparent surfaces in any order by using tile shaders and image blocks. |
| App architecture | A C/Objective-C header, Metal, Objective-C sample with the source-visible chain main → AAPLViewController → TransparentFragmentStore → AAPLRenderer → Cocoa / simd APIs. |
| Main patterns | View-controller organization, Delegate or data-source callbacks, Central store |
| Project style | 15 scanned source file(s) across C/Objective-C header, Metal, Objective-C, organized around ranked entry, type, and file boundaries. |
| Execution model | No structured execution marker indexed; callback threading requires source review. |
| State/event model | No structured observation or publisher-scheduling marker indexed. |
| Key frameworks/packages | TargetConditionals.h, Cocoa, simd, stdlib.h, assert.h; these are source dependencies, not architecture labels. |
Project structure
Source bundle/
├── Application/
│ ├── main.m
│ ├── AAPLAppDelegate.h
│ ├── AAPLAppDelegate.m
│ ├── AAPLViewController.h
│ ├── AAPLViewController.m
│ ├── WindowSceneDelegate.h
│ └── WindowSceneDelegate.m
└── Renderer/
├── AAPLRenderer.h
├── AAPLRenderer.m
├── Shaders/
│ └── AAPLShaders.metal
├── AAPLActor.h
└── AAPLActor.m
Structure observations
- Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
- Primary languages: C/Objective-C header, Metal, Objective-C.
- The verified tree contains 7 project/configuration file(s) and 7 source declaration(s).
Overall architecture
flowchart LR
N1["main"]
N2["AAPLViewController"]
N3["TransparentFragmentStore"]
N4["AAPLRenderer"]
N5["Cocoa / simd APIs"]
N1 --> N2
N2 --> N3
N3 --> N4
N4 --> N5
Reference code
Application/main.m:10 — architecture anchor
int main(int argc, char * argv[])
{
// ...
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AAPLAppDelegate class]));
// ...
}Interpretation
The arrows summarize the source-visible entry, role-named types or folders, and framework direction; when nodes come from structural folders, the sequence is a high-level interpretation rather than proof that every adjacent node calls the next. Ownership is claimed only where the next section cites a stored property or assignment. The diagram is intentionally limited to the dominant path into Metal.
Ownership and state
classDiagram
WindowSceneDelegate o-- UIWindow : window
AAPLRenderer o-- BOOL : supportsOrderIndependentTransparency
AAPLRenderer o-- BOOL : enableOrderIndependentTransparency
AAPLRenderer o-- BOOL : enableRotation
Ownership evidence
Application/WindowSceneDelegate.h:18 — stored dependency or nearest verified ownership anchor
#if TARGET_OS_IPHONE
@property (nonatomic, strong) UIWindow *window;
#endif| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
WindowSceneDelegate |
UIWindow (window) |
retains or copies an assigned value | Header-visible collaborators |
AAPLRenderer |
BOOL (supportsOrderIndependentTransparency) |
stores or receives | The declaring implementation writes; property clients read |
AAPLRenderer |
BOOL (enableOrderIndependentTransparency) |
stores or receives | Header-visible collaborators |
AAPLRenderer |
BOOL (enableRotation) |
stores or receives | Header-visible collaborators |
Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.
Concurrency, scheduling, and thread safety
Evidence limit: actor isolation, async/await, or Task creation does not by itself prove background-thread execution; Sendable conformance alone does not prove thread-safe mutation.
No source-visible execution, scheduling, or synchronization boundary was found in the indexed source.
@MainActor/MainActor.run, DispatchQueue.main, and RunLoop.main are reported as distinct isolation, queue, and event-loop mechanisms. A plain Task is kept separate from Task.detached; neither is labeled as a background thread.
State propagation, frameworks, and dependencies
Evidence limit: an import proves a source-level compilation dependency at the cited line; it does not prove runtime use, architectural adoption, or whether a Swift package is a direct application dependency.
| Category | Mechanism or module | Verified role | Evidence |
|---|---|---|---|
| Source import | TargetConditionals.h |
The cited file imports this module; runtime use and architectural role are not inferred. | Application/AAPLAppDelegate.h:8 |
| Source import | Cocoa |
The cited file imports this module; runtime use and architectural role are not inferred. | Application/AAPLAppDelegate.h:20 |
| Source import | simd |
The cited file imports this module; runtime use and architectural role are not inferred. | Renderer/AAPLMathUtilities.h:9 |
| Source import | stdlib.h |
The cited file imports this module; runtime use and architectural role are not inferred. | Renderer/AAPLMathUtilities.h:8 |
| Source import | assert.h |
The cited file imports this module; runtime use and architectural role are not inferred. | Renderer/AAPLMathUtilities.m:10 |
| Source import | Foundation |
The cited file imports this module; runtime use and architectural role are not inferred. | Application/WindowSceneDelegate.h:8 |
receive(on:) describes downstream delivery scheduling, while subscribe(on:) describes upstream subscription/request/cancel scheduling. An import Combine alone establishes neither behavior nor a Store, reducer, Redux, or other application architecture.
Class and protocol design
Application/AAPLAppDelegate.h:14 — representative type boundary
#if TARGET_OS_IPHONE
@interface AAPLAppDelegate : UIResponder <UIApplicationDelegate>
@end
#endif| Type | Responsibility | Depends on or conforms to |
|---|---|---|
AAPLAppDelegate |
Receives callback-driven events | UIResponder, UIApplicationDelegate |
AAPLViewController |
View lifecycle, callbacks, and feature coordination | PlatformViewController |
WindowSceneDelegate |
Receives callback-driven events | UIResponder, UIWindowSceneDelegate |
AAPLRenderer |
Owns drawing, GPU, or presentation processing | NSObject, MTKViewDelegate |
TransparentFragmentStore |
Centralized state or persistence access | Concrete collaborators/imported frameworks |
TransparentFragmentValues |
Represents a feature value or composable behavior | Concrete collaborators/imported frameworks |
AAPLActor |
Defines a feature-specific type boundary | NSObject |
No local protocol conformance is claimed as protocol-oriented design; external framework conformances are listed only as dependencies.
Access control
| Symbol | Access | Verified effect | Likely rationale |
|---|---|---|---|
window (Application/WindowSceneDelegate.h:18) |
header-visible |
The declaration is exposed to translation units that import the header. | Inference: declare a contract needed by other Objective-C/C translation units. |
color (Renderer/AAPLActor.h:21) |
header-visible |
The declaration is exposed to translation units that import the header. | Inference: declare a contract needed by other Objective-C/C translation units. |
position (Renderer/AAPLActor.h:23) |
header-visible |
The declaration is exposed to translation units that import the header. | Inference: declare a contract needed by other Objective-C/C translation units. |
rotation (Renderer/AAPLActor.h:25) |
header-visible |
The declaration is exposed to translation units that import the header. | Inference: declare a contract needed by other Objective-C/C translation units. |
Reference code
Application/WindowSceneDelegate.h:18 — representative boundary
#if TARGET_OS_IPHONE
@property (nonatomic, strong) UIWindow *window;
#endifSwift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.
Logic ownership and placement
| Logic | Owning type or file | Placement rationale |
|---|---|---|
| View lifecycle, callbacks, and feature coordination | AAPLViewController |
The source’s Controller suffix makes this role explicit. |
| Receives callback-driven events | AAPLAppDelegate, WindowSceneDelegate |
The source’s Delegate suffix makes this role explicit. |
| Owns drawing, GPU, or presentation processing | AAPLRenderer |
The source’s Renderer suffix makes this role explicit. |
| Centralized state or persistence access | TransparentFragmentStore |
The source’s Store suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| View-controller organization | Application/AAPLViewController.h:21 |
A controller is the verified coordination boundary; this is MVC-style only where a separate model is present. |
| Delegate or data-source callbacks | Application/AAPLAppDelegate.h:14 |
Callback protocols invert event delivery back into the sample’s owner. |
| Central store | Renderer/Shaders/AAPLShaders.metal:79 |
A store-named type centralizes feature state or persistence. |
Main application flow
sequenceDiagram
participant AAPLViewController
participant AAPLRenderer
participant _renderer
participant _orderIndependentTransparencyControl
AAPLViewController->>AAPLViewController: viewDidLoad()
AAPLViewController->>AAPLRenderer: initWithMetalKitView()
AAPLViewController->>_renderer: mtkView()
AAPLViewController->>_orderIndependentTransparencyControl: setSelected()
Reference code
Application/AAPLViewController.m:40 — viewDidLoad()
- (void)viewDidLoad
{
[super viewDidLoad];
_mtkView = (MTKView*)self.view;
_mtkView.device = MTLCreateSystemDefaultDevice();
NSAssert(_mtkView.device, @"Metal is not supported on this device");
_renderer = [[AAPLRenderer alloc] initWithMetalKitView:_mtkView];
NSAssert(_renderer, @"Renderer failed to initialize");
[_renderer mtkView:_mtkView drawableSizeWillChange:_mtkView.drawableSize];
_mtkView.delegate = _renderer;
if (_renderer.supportsOrderIndependentTransparency)
{
_orderIndependentTransparencyControl.enabled = YES;
}
else
{
_orderIndependentTransparencyControl.enabled = NO;
}
NSUInteger segmentSelectionIndex = (_renderer.enableOrderIndependentTransparency) ? 0 : 1;
#if TARGET_OS_IPHONE
_orderIndependentTransparencyControl.selectedSegmentIndex = segmentSelectionIndex;
#else
[_orderIndependentTransparencyControl setSelected:YES forSegment:segmentSelectionIndex];
#endif
}Naming conventions
- Types: Controller: AAPLViewController; Delegate: AAPLAppDelegate, WindowSceneDelegate; Renderer: AAPLRenderer; Store: TransparentFragmentStore.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
application,applicationShouldTerminateAfterLastWindowClosed,viewDidLoad,acceptsFirstResponder,updateTransparencyMethod,toggleRotation,viewDidAppear,scene. - Files:
Application/AAPLAppDelegate.h,Application/AAPLAppDelegate.m,Application/AAPLViewController.h,Application/AAPLViewController.m,Application/WindowSceneDelegate.h,Application/WindowSceneDelegate.m.
Architecture takeaways
mainis the main source-visible entry or composition anchor for this sample.- Framework work reaches Cocoa, simd, Shaders, UIKit through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
- Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
- Access-control conclusions separate verified language visibility from the likely design rationale.
- The source does not justify labeling the design protocol-oriented.
Source map
| Source file | Relevant symbols |
|---|---|
Application/main.m |
Cited implementation, Feature implementation |
Application/WindowSceneDelegate.h |
Cited implementation, window, Foundation, WindowSceneDelegate |
Application/AAPLAppDelegate.h |
AAPLAppDelegate, Cited implementation, TargetConditionals.h, Cocoa |
Renderer/AAPLActor.h |
color, position, rotation, AAPLActor |
Application/AAPLViewController.h |
AAPLViewController |
Renderer/Shaders/AAPLShaders.metal |
TransparentFragmentStore, TransparentFragmentValues |
Renderer/AAPLMathUtilities.h |
simd, stdlib.h, Feature implementation |
Renderer/AAPLMathUtilities.m |
assert.h, Feature implementation |
Application/AAPLAppDelegate.m |
AAPLAppDelegate |
Application/AAPLViewController.m |
AAPLViewController |
Application/WindowSceneDelegate.m |
WindowSceneDelegate |
Renderer/AAPLRenderer.h |
AAPLRenderer |
Renderer/AAPLRenderer.m |
AAPLRenderer |
Renderer/AAPLActor.m |
AAPLActor |
Renderer/Shaders/AAPLShaderTypes.h |
Feature implementation |