Compose Drawing Mastery - Part 2 - Transformations

1. Breaking the Static Barrier In Part 1 of this series, we stepped off the declarative path and into the imperative island of DrawScope. We learned that custom drawing is about understanding the pipeline, not just about pixels. We built a precision grid, wrestled with anti-aliasing, and discovered why Path objects are the performance architect's secret weapon. Part 1 of this series DrawScope understanding the pipeline Path But if you stop there, your UI remains a collection of static stamps. To build interfaces that feel "alive" - physics-based loaders, interactive dials, or fluid transitions - you have to stop moving objects and start moving the universe they live in. The Paradigm Shift When I first encountered transformation functions in DrawScope, I did what any reasonable developer would do: I called rotate(45f) and expected my rectangle to rotate 45 degrees. DrawScope rotate(45f) But then I tried to build something more complex - a clock with a rotating minute hand that had a small circle at its tip. I figured: rotate the hand, then draw the circle at the end. An hour later, my circle was flying off into coordinates that made no mathematical sense, and I was questioning my understanding of basic geometry. I searched for help and found the same advice everywhere: You're transforming the coordinate system, not the drawing. You're transforming the coordinate system, You're transforming the coordinate system, not the drawing. not the drawing. But what does that actually mean? But what does that actually mean? Here's what I eventually realized: understanding transformations requires building a new mental model. Not just learning the API, but fundamentally changing how you visualize what's happening when you call rotate() or translate(). new mental model rotate() translate() Here, we're going to build that mental model from the ground up. We'll use visual analogies, walk through exactly what happens to the coordinate grid, and by the end, the phrase "transforming the coordinate system" will actually mean something concrete and useful. And by the end of this article, we'll be able to build something beautiful, like an Orbital Loader: a cosmic animation with planets orbiting a pulsing core, moons orbiting planets, trailing particle effects, and expanding energy rings. It looks like this: Orbital Loader 2. The Matrix Mental Model - What's Really Happening When documentation says "you're transforming the coordinate system," it sounds abstract. Let's make it concrete by understanding what's actually happening under the hood. Spoiler: it's just multiplication. And once you see it, you can't unsee it. 2.1 Coordinates Are Already Matrix Math Every point you specify in DrawScope - say, Offset(3f, 2f) - is secretly participating in matrix multiplication. You just don't see it because the math is invisible when nothing is transformed. DrawScope Offset(3f, 2f) This is because your "normal" coordinate system is defined by two basis vectors: basis vectors X-axis: Points right with magnitude 1 → (1, 0) Y-axis: Points down with magnitude 1 → (0, 1) X-axis: Points right with magnitude 1 → (1, 0) X-axis: (1, 0) Y-axis: Points down with magnitude 1 → (0, 1) Y-axis: (0, 1) These basis vectors form what's called the Identity Matrix: Identity Matrix Identity Matrix: ┌ ┐ │ 1 0 │ ← X basis vector (1, 0) │ 0 1 │ ← Y basis vector (0, 1) └ ┘ Identity Matrix: ┌ ┐ │ 1 0 │ ← X basis vector (1, 0) │ 0 1 │ ← Y basis vector (0, 1) └ ┘ When you draw at point (3, 2), here's what actually happens: (3, 2) Your Point × Identity Matrix = Screen Position (3, 2) × ┌ 1 0 ┐ = (3×1 + 2×0, 3×0 + 2×1) = (3, 2) └ 0 1 ┘ Your Point × Identity Matrix = Screen Position (3, 2) × ┌ 1 0 ┐ = (3×1 + 2×0, 3×0 + 2×1) = (3, 2) └ 0 1 ┘ The result equals the input. That's why it's called the "identity" - it changes nothing. Why does this matter? Because transformations work by changing those basis vectors. When you call rotate() or scale(), you're not moving your shapes - you're redefining what "right" and "down" mean. Why does this matter? changing those basis vectors rotate() scale() 2.2 The Transformation Formula Here's how any point transforms through a matrix: [a b] [x] [a·x + b·y] x = [c d] [y] [c·x + d·y] [a b] [x] [a·x + b·y] x = [c d] [y] [c·x + d·y] Your original X coordinate gets scaled by a and mixed with Y (via b). Your original Y coordinate gets scaled by d and mixed with X (via c). a b d c This formula is the engine behind every transformation. Let's see it in action. 2.3 Scale: Stretching the Grid The simplest transformation to visualize is scaling. Let's double everything: scaling [2 0] [x] [2x] x = [0 2] [y] [2y] [2 0] [x] [2x] x = [0 2] [y] [2y] What happens to our rectangle? Original Point Calculation Transformed Point A (1, 1) (2×1, 2×1) (2, 2) B (3, 1) (2×3, 2×1) (6, 2) C (3, 2) (2×3, 2×2) (6, 4) D (1, 2) (2×1, 2×2) (2, 4) Original Point Calculation Transformed Point A (1, 1) (2×1, 2×1) (2, 2) B (3, 1) (2×3, 2×1) (6, 2) C (3, 2) (2×3, 2×2) (6, 4) D (1, 2) (2×1, 2×2) (2, 4) Original Point Calculation Transformed Point Original Point Original Point Calculation Calculation Transformed Point Transformed Point A (1, 1) (2×1, 2×1) (2, 2) A (1, 1) A (1, 1) (2×1, 2×1) (2×1, 2×1) (2, 2) (2, 2) B (3, 1) (2×3, 2×1) (6, 2) B (3, 1) B (3, 1) (2×3, 2×1) (2×3, 2×1) (6, 2) (6, 2) C (3, 2) (2×3, 2×2) (6, 4) C (3, 2) C (3, 2) (2×3, 2×2) (2×3, 2×2) (6, 4) (6, 4) D (1, 2) (2×1, 2×2) (2, 4) D (1, 2) D (1, 2) (2×1, 2×2) (2×1, 2×2) (2, 4) (2, 4) X basis: (1, 0) → (2, 0) - "one unit right" now spans 2 pixels Y basis: (0, 1) → (0, 2)- "one unit down" now spans 2 pixels X basis: (1, 0) → (2, 0) - "one unit right" now spans 2 pixels (1, 0) (2, 0) Y basis: (0, 1) → (0, 2)- "one unit down" now spans 2 pixels (0, 1) (0, 2) When you call scale(2f, 2f) in DrawScope, this is exactly what's happening under the hood - your coordinate grid gets stretched, and every drawing command operates in this new, larger universe. scale(2f, 2f) 2.4 Non-Uniform Scale: Different Axes, Different Rules What if we only stretch horizontally? [2 0] [x] [2x] x = [0 1] [y] [ y] [2 0] [x] [2x] x = [0 1] [y] [ y] The rectangle stretches horizontally while keeping its height. The X basis vector changed to (2, 0), but the Y basis vector stayed at (0, 1). (2, 0) (0, 1) 2.5 Rotation: The Basis Vectors Dance Now for the transformation that confuses developers most: rotation. Unlike scale and shear, rotation changes both basis vectors simultaneously while keeping them perpendicular and equal length. rotation both The rotation matrix for angle θ (clockwise, since Y points down in canvas coordinates): [cos(θ) -sin(θ)] [sin(θ) cos(θ)] [cos(θ) -sin(θ)] [sin(θ) cos(θ)] Let's trace through a 60° rotation. First, the matrix values: cos(60°) = 0.5 sin(60°) ≈ 0.866 [0.5 -0.866] [0.866 0.5 ] cos(60°) = 0.5 sin(60°) ≈ 0.866 [0.5 -0.866] [0.866 0.5 ] X basis (1, 0) transforms to (0.5, 0.866) — it now points down-and-right Y basis (0, 1) transforms to (-0.866, 0.5) — it now points up-and-right X basis (1, 0) transforms to (0.5, 0.866) — it now points down-and-right X basis (1, 0) (0.5, 0.866) Y basis (0, 1) transforms to (-0.866, 0.5) — it now points up-and-right Y basis (0, 1) (-0.866, 0.5) The entire coordinate grid has rotated 60° clockwise around the origin. "Right" no longer means right. "Down" no longer means down. But crucially, X and Y remain perpendicular — rotation preserves the grid's shape, just tilts it. Watch the rectangle swing downward and toward the center. Points farther from the origin travel longer arcs — the corners trace circles of different radii, all centered at (0, 0). The geometric intuition: Every point orbits the pivot. A point at distance r from origin stays at distance r, but its angle changes by θ. The geometric intuition: r r This is why: Points on the right swing downward (in canvas coordinates) Points farther from pivot move more dramatically on screen The shape itself doesn't distort, just relocates Points on the right swing downward (in canvas coordinates) Points farther from pivot move more dramatically on screen The shape itself doesn't distort, just relocates Note on Pivot Point: This example rotates around the origin (0, 0), which is what a pure 2×2 rotation matrix represents. In practice, you'll often want to rotate around a shape's center or another point. DrawScope's rotate(degrees, pivot) handles this by internally combining translation and rotation — we'll explore pivot mechanics in futher when we discuss transformation order. Note on Pivot Point: rotate(degrees, pivot) 2.6 The Matrix as a New Reality When you specify drawRect(topLeft = Offset(1f, 1f), size = Size(2f, 1f)), you're saying "start at position (1,1) in the current coordinate system." If that coordinate system has been scaled, sheared, or rotated, your rectangle appears differently on screen — but your drawing code doesn't change. drawRect(topLeft = Offset(1f, 1f), size = Size(2f, 1f)) This is why transformation blocks look like this in DrawScope: withTransform({ // Modify the coordinate system scale(2f, 2f) }) { // Draw in the modified system drawRect(Color.Blue, topLeft = Offset(1f, 1f), size = Size(2f, 1f)) // You write the same coordinates, but they mean different things now } withTransform({ // Modify the coordinate system scale(2f, 2f) }) { // Draw in the modified system drawRect(Color.Blue, topLeft = Offset(1f, 1f), size = Size(2f, 1f)) // You write the same coordinates, but they mean different things now } You're not transforming the rectangle. You're transforming the meaning of (1, 1). (1, 1) 2.7 A Word About Translation You might have noticed something missing from our matrix examples: translation. How do you shift the entire coordinate system 100 pixels to the right? translation Problem is, a 2×2 matrix cannot represent translation. a 2×2 matrix cannot represent translation. Canvas (and by extension, DrawScope) actually operates on 3×3 matrices that look like this: [a b tx] [x] [ax + by + tx] [c d ty] × [y] = [cx + dy + ty] [0 0 1] [1] [ 1 ] [a b tx] [x] [ax + by + tx] [c d ty] × [y] = [cx + dy + ty] [0 0 1] [1] [ 1 ] -Here, 2x2 Core (a,b,c,d) handles your rotation and scaling, third column (tx, ty) represents the Translation Vector and the third row is required to keep the matrix square for multiplication. Translation Vector Math behind this is quite interesting (look up homogeneous coordinates, if you want to really deep dive), but rather complicated to explore it here. Just know, that it doesn't matter, 2x2, or 3x3, basic principle is always same for all transformations. 2.8 Why This Matters for Animation Once you internalize this model, animations become a matter of smoothly changing the basis vectors over time: smoothly changing the basis vectors Pulsing effect: Oscillate the diagonal elements between 0.9 and 1.1 Spinning: Rotate the basis vectors around the origin Wave distortion: Animate the shear values with a sine function Pulsing effect: Oscillate the diagonal elements between 0.9 and 1.1 Pulsing effect Spinning: Rotate the basis vectors around the origin Spinning Wave distortion: Animate the shear values with a sine function Wave distortion Instead of recalculating every point's position per frame, you modify one matrix and let the GPU do the rest. This is why transformation-based animation is so efficient - and why understanding the matrix model unlocks creative possibilities. 3. The Compose Drawing Architecture — Context, Canvas, and Transforms Before we dive into practical transformations, let's peek behind the curtain. Understanding the architecture isn't just academic curiosity - it's what separates developers who debug by intuition from those who debug by trial and error. When you call rotate(45f) inside a drawBehind block, what actually happens? The answer involves four interconnected pieces that Compose orchestrates on your behalf. rotate(45f) drawBehind 3.1 The Hierarchy You're Actually Working With DrawScope (The UI Layer): This is the friendly, developer-facing interface. It provides density-aware helpers like dp.toPx() and the standard drawing functions (drawCircle, drawRect). It’s designed to be safe and idiomatic. But DrawScope itself doesn't draw anything. It's a facade. DrawScope (The UI Layer): dp.toPx() drawCircle drawRect DrawContext (The Bridge): Accessed via the drawContext property, this is the internal state-holder. DrawContext holds three critical references: DrawContext (The Bridge): drawContext // Inside any DrawScope, you can access: drawContext.size // The final pixel dimensions drawContext.canvas // The actual drawing surface drawContext.transform // The transformation controller // Inside any DrawScope, you can access: drawContext.size // The final pixel dimensions drawContext.canvas // The actual drawing surface drawContext.transform // The transformation controller Canvas (The Native Engine): This is the actual androidx.compose.ui.graphics.Canvas. It’s a wrapper around the platform’s native canvas (Skia on Android). This abstraction is what makes Compose truly multiplatform, but for our purposes, it behaves like the Canvas you know: it's where drawing commands ultimately execute. Canvas (The Native Engine): androidx.compose.ui.graphics.Canvas DrawTransform (The Matrix Manager): This is the "brain" behind the transformations we discussed in Section 2. It manages the 3x3 matrix and handles the clipping and translation state. DrawTransform (The Matrix Manager): When you call rotate() or translate() inside a withTransform block, you're actually invoking methods on this interface: rotate() translate() withTransform // What withTransform actually does (simplified): inline fun DrawScope.withTransform( transformBlock: DrawTransform.() -> Unit, drawBlock: DrawScope.() -> Unit ) { drawContext.canvas.save() // Snapshot current state drawContext.transform.transformBlock() // Apply your transformations drawBlock() // Execute drawing commands drawContext.canvas.restore() // Revert to snapshot } // What withTransform actually does (simplified): inline fun DrawScope.withTransform( transformBlock: DrawTransform.() -> Unit, drawBlock: DrawScope.() -> Unit ) { drawContext.canvas.save() // Snapshot current state drawContext.transform.transformBlock() // Apply your transformations drawBlock() // Execute drawing commands drawContext.canvas.restore() // Revert to snapshot } Notice, that withTransform block structure guarantees that save() and restore() are always paired. Forgetting one of these calls were common mistake in classic View System drawing times. But here, you physically cannot forget to restore — the lambda ends, the state restores. withTransform save() restore() 3.2 When to Reach Through the Abstraction For 95% of custom drawing work, you'll never touch drawContext directly. DrawScope's methods are sufficient and safer. drawContext But occasionally, you need the raw canvas - perhaps for interoperability with legacy drawing code or accessing platform-specific features not yet wrapped by Compose: Modifier.drawBehind { // Access the underlying canvas when absolutely necessary drawContext.canvas.nativeCanvas.apply { // Now you have android.graphics.Canvas // Use sparingly, cause you're bypassing Compose's safety } } Modifier.drawBehind { // Access the underlying canvas when absolutely necessary drawContext.canvas.nativeCanvas.apply { // Now you have android.graphics.Canvas // Use sparingly, cause you're bypassing Compose's safety } } 3.3 Why This Architecture Matters for Performance Here's the practical insight: all transformation operations happen on the GPU. all transformation operations happen on the GPU When you call rotate(45f), Compose doesn't recalculate every coordinate. It modifies the transformation matrix - a small array of numbers. The GPU then applies this matrix to every vertex in a single, massively parallel operation. rotate(45f) This is why transformations are essentially "free" compared to redrawing. Rotating 1000 points costs the same as rotating 10 - the GPU doesn't care about quantity when it's just matrix multiplication. Your job is to describe transformations, not calculate them. Let Compose and the GPU handle the math. describe transformations 4. The Transformation Stack — Mechanics & Mastery 4.1 The Core Operations at a Glance Here's your quick reference for what each transformation does: Operation What It Does Default Pivot translate(left, top) Shifts the origin point N/A rotate(degrees, pivot) Rotates coordinate axes Center of bounds scale(scaleX, scaleY, pivot) Stretches/compresses the grid (0, 0) clipRect / clipPath Restricts drawable area N/A inset(left, top, right, bottom) Shrinks drawable bounds N/A Operation What It Does Default Pivot translate(left, top) Shifts the origin point N/A rotate(degrees, pivot) Rotates coordinate axes Center of bounds scale(scaleX, scaleY, pivot) Stretches/compresses the grid (0, 0) clipRect / clipPath Restricts drawable area N/A inset(left, top, right, bottom) Shrinks drawable bounds N/A Operation What It Does Default Pivot Operation Operation What It Does What It Does Default Pivot Default Pivot translate(left, top) Shifts the origin point N/A translate(left, top) translate(left, top) translate(left, top) Shifts the origin point Shifts the origin point N/A N/A rotate(degrees, pivot) Rotates coordinate axes Center of bounds rotate(degrees, pivot) rotate(degrees, pivot) rotate(degrees, pivot) Rotates coordinate axes Rotates coordinate axes Center of bounds Center of bounds scale(scaleX, scaleY, pivot) Stretches/compresses the grid (0, 0) scale(scaleX, scaleY, pivot) scale(scaleX, scaleY, pivot) scale(scaleX, scaleY, pivot) Stretches/compresses the grid Stretches/compresses the grid (0, 0) (0, 0) clipRect / clipPath Restricts drawable area N/A clipRect / clipPath clipRect / clipPath clipRect clipPath Restricts drawable area Restricts drawable area N/A N/A inset(left, top, right, bottom) Shrinks drawable bounds N/A inset(left, top, right, bottom) inset(left, top, right, bottom) inset(left, top, right, bottom) Shrinks drawable bounds Shrinks drawable bounds N/A N/A 4.2 Clipping: The Subtractive Transformation The first three operations - translate, rotate, scale - all transform where things appear and, in my opinion, easily understandable. Clipping is fundamentally different - It restricts where drawing is allowed to happen. transform restricts where drawing is allowed to happen Think of it as placing a stencil over your canvas. You can still call any drawing command you want, but only the parts that fall within the clipped region will actually appear. @Composable fun ClipRectSplitExample() { Box( modifier = Modifier .size(340.dp) .drawBehind { // Draw dark background for the full area drawRect(color = Color(0xFF1A1A2E)) // Clip complex pattern to right half only clipRect( left = size.width / 2, top = 0f, right = size.width, bottom = size.height ) { // Without clipRect, we'd need complex math to draw partial circles val radius = size.width * 0.35f drawCircle( color = Color.Red, radius = radius, center = Offset(size.width * 0.3f, size.height * 0.3f) ) drawCircle( color = Color.Blue, radius = radius, center = Offset(size.width * 0.7f, size.height * 0.25f) ) drawCircle( color = Color.Green, radius = radius, center = Offset(size.width * 0.35f, size.height * 0.7f) ) drawCircle( color = Color.Magenta, radius = radius, center = Offset(size.width * 0.75f, size.height * 0.75f) ) } }, contentAlignment = Alignment.Center ) { Text( text = "CLIP", color = Color.White, style = MaterialTheme.typography.displayMedium ) } } @Composable fun ClipRectSplitExample() { Box( modifier = Modifier .size(340.dp) .drawBehind { // Draw dark background for the full area drawRect(color = Color(0xFF1A1A2E)) // Clip complex pattern to right half only clipRect( left = size.width / 2, top = 0f, right = size.width, bottom = size.height ) { // Without clipRect, we'd need complex math to draw partial circles val radius = size.width * 0.35f drawCircle( color = Color.Red, radius = radius, center = Offset(size.width * 0.3f, size.height * 0.3f) ) drawCircle( color = Color.Blue, radius = radius, center = Offset(size.width * 0.7f, size.height * 0.25f) ) drawCircle( color = Color.Green, radius = radius, center = Offset(size.width * 0.35f, size.height * 0.7f) ) drawCircle( color = Color.Magenta, radius = radius, center = Offset(size.width * 0.75f, size.height * 0.75f) ) } }, contentAlignment = Alignment.Center ) { Text( text = "CLIP", color = Color.White, style = MaterialTheme.typography.displayMedium ) } } clipPath: When Rectangles Aren't Enough clipPath is where things get interesting. Because a Path can be anything—a star, a logo, or a complex organic blob - clipping to a path allows you to create "portal" effects. clipPath Path clipRect handles rectangular masks, but real UI rarely stays rectangular. clipPath lets you define arbitrary shapes as your stencil: clipRect clipPath val heartPath = Path().apply { // ... heart shape geometry } withTransform({ clipPath(heartPath) }) { // Everything drawn here will be heart-shaped drawRect(Color.Red, size = size) // Fills only the heart // Even images respect the clip drawImage(photo) // Photo appears in heart shape } val heartPath = Path().apply { // ... heart shape geometry } withTransform({ clipPath(heartPath) }) { // Everything drawn here will be heart-shaped drawRect(Color.Red, size = size) // Fills only the heart // Even images respect the clip drawImage(photo) // Photo appears in heart shape } Architectural Tip: Clipping is expensive if overused, especially clipPath with complex anti-aliased edges. Use clipRect(which is highly optimized on the hardware level) whenever possible. Save clipPath for high-impact visual "hero" moments. Architectural Tip: clipPath clipRect clipPath 4.3 Order of Operations — Why B Then A = A Then B Because transformations are matrix multiplications, the order in which you call them changes the final result. In DrawScope, transformations are applied in the order they are written (top to bottom). order in which you call them changes the final result. DrawScope Think of it this way: Each operation transforms the world for the next operation. Each operation transforms the world for the next operation. Scenario A: Translate, then Rotate You move the origin 100px to the right. You rotate the grid 45°. Result: The object is 100px away and spinning around its own new center. You move the origin 100px to the right. You rotate the grid 45°. Result: The object is 100px away and spinning around its own new center. Result: own Scenario B: Rotate, then Translate You rotate the entire world 45°. "Right" is now a diagonal line pointing down-right. You move the origin 100px "right." Result: The object moves 100px along that diagonal line. You rotate the entire world 45°. "Right" is now a diagonal line pointing down-right. You move the origin 100px "right." Result: The object moves 100px along that diagonal line. Result: along that diagonal line The Rule of Thumb: If you want an object to spin in place, Translate to its position first, then Rotate. If you want an object to orbit the center (like a planet), Rotate first, then Translate. The Rule of Thumb: Translate Rotate Rotate Translate Your Turn: Build the Orbital Loader Remember that cosmic loader from the introduction? The one with planets, moons, trails, and energy rings? You now have every concept needed to build it. You now have every concept needed to build it. You now have the mental model of the matrix, an understanding of the Compose drawing architecture, and the rules of transformation order. Here's your implementation roadmap: Establish the Gravitational Anchor Because the canvas origin (0,0) is the top-left corner, calculate a center Offset to serve as your coordinate anchor. Draw the Starfield Background here using a loop of circles with randomized alpha and radii to create depth. The Pulsing Core Instead of manually changing radius values, apply a corePulse animation to the coordinate system. Using Brush.radialGradient, render a sun that expands and contracts, creating a glow that radiates from the center of your "universe". Planet Trails (The Temporal Ghost) To simulate fluid motion, draw "ghosts" of the planets. The Logic: Reuse the planet’s rotation logic but subtract incremental degrees from the current orbitAngle for each segment. The Benefit: Since these are GPU-level transformations, rendering 12–16 trail circles is essentially "free" compared to calculating complex paths. The Orbital "Rotate-Translate" Pattern To make a planet orbit, follow the Rule of Thumb: Rotate first, then Translate. Rotate: Tilt the coordinate system by the orbitAngle around the center. Translate: Move the origin "right" along the newly rotated X-axis by the orbitRadius. Draw: Place the planet at the new Offset.Zero. It will appear to orbit perfectly. Nested Moon Transformations By nesting a withTransform block inside a planet's transformation, the moon’s coordinates become relative to the planet, not the sun. The outer transform handles the planet’s orbit around the core. The inner transform handles the moon’s orbit, using the planet’s current position as its own (0,0) origin. Full implementation: Link to complete code Establish the Gravitational Anchor Because the canvas origin (0,0) is the top-left corner, calculate a center Offset to serve as your coordinate anchor. Draw the Starfield Background here using a loop of circles with randomized alpha and radii to create depth. Establish the Gravitational Anchor center Starfield Background The Pulsing Core Instead of manually changing radius values, apply a corePulse animation to the coordinate system. Using Brush.radialGradient, render a sun that expands and contracts, creating a glow that radiates from the center of your "universe". The Pulsing Core corePulse Brush.radialGradient Planet Trails (The Temporal Ghost) To simulate fluid motion, draw "ghosts" of the planets. The Logic: Reuse the planet’s rotation logic but subtract incremental degrees from the current orbitAngle for each segment. The Benefit: Since these are GPU-level transformations, rendering 12–16 trail circles is essentially "free" compared to calculating complex paths. Planet Trails (The Temporal Ghost) The Logic: Reuse the planet’s rotation logic but subtract incremental degrees from the current orbitAngle for each segment. The Benefit: Since these are GPU-level transformations, rendering 12–16 trail circles is essentially "free" compared to calculating complex paths. The Logic: Reuse the planet’s rotation logic but subtract incremental degrees from the current orbitAngle for each segment. The Logic: The Benefit: Since these are GPU-level transformations, rendering 12–16 trail circles is essentially "free" compared to calculating complex paths. The Benefit: The Orbital "Rotate-Translate" Pattern To make a planet orbit, follow the Rule of Thumb: Rotate first, then Translate. Rotate: Tilt the coordinate system by the orbitAngle around the center. Translate: Move the origin "right" along the newly rotated X-axis by the orbitRadius. Draw: Place the planet at the new Offset.Zero. It will appear to orbit perfectly. The Orbital "Rotate-Translate" Pattern Rule of Thumb Rotate first, then Translate Rotate: Tilt the coordinate system by the orbitAngle around the center. Translate: Move the origin "right" along the newly rotated X-axis by the orbitRadius. Draw: Place the planet at the new Offset.Zero. It will appear to orbit perfectly. Rotate: Tilt the coordinate system by the orbitAngle around the center. Rotate: Translate: Move the origin "right" along the newly rotated X-axis by the orbitRadius. Translate: Draw: Place the planet at the new Offset.Zero. It will appear to orbit perfectly. Draw: Nested Moon Transformations By nesting a withTransform block inside a planet's transformation, the moon’s coordinates become relative to the planet, not the sun. The outer transform handles the planet’s orbit around the core. The inner transform handles the moon’s orbit, using the planet’s current position as its own (0,0) origin. Full implementation: Link to complete code Nested Moon Transformations The outer transform handles the planet’s orbit around the core. The inner transform handles the moon’s orbit, using the planet’s current position as its own (0,0) origin. Full implementation: Link to complete code The outer transform handles the planet’s orbit around the core. The outer transform handles the planet’s orbit around the core. outer transform The inner transform handles the moon’s orbit, using the planet’s current position as its own (0,0) origin. Full implementation: Link to complete code The inner transform handles the moon’s orbit, using the planet’s current position as its own (0,0) origin. inner transform Full implementation: Link to complete code Full implementation: Link to complete code