Mission 19: Transformative Layers
The tactical starmap's animations are dropping frames. A performance profile shows heavy 'paint' events on the CPU. You must isolate the animated elements to their own layer to enable GPU acceleration.
Mission Objective
Step 1 / 1
System Briefing: GPU Acceleration
The bridge's new 3D tactical starmap is causing motion sickness among the crew. When fleets are moved, the animation is "janky" and drops frames because the main system processor (CPU) is struggling to recalculate styles and repaint the screen on every frame. We need to offload this work to the specialized Graphics Processing Unit (GPU).
Compositor Layers and Hardware Acceleration
Modern browsers can hand off certain tasks, like complex transforms and opacity changes, to the GPU. To do this, the element must be promoted to its own "compositor layer." This is like telling the browser, "Hey, this element is going to change a lot, so treat it like a separate image and just move it around with the GPU instead of constantly repainting it with the CPU."
The will-change Property
The modern, standard way to signal this optimization is with the will-change property. It's a hint to the browser about which properties you expect to animate.
/* Tell the browser to optimize for upcoming transform animations */
.ship-icon {
will-change: transform;
}
Old Hack: You might see older code using transform: translateZ(0); or transform: translate3d(0,0,0);. This was a common "hack" to trick the browser into creating a GPU layer. While it still works, will-change is the more explicit and correct way to achieve this.