Constrained profile for Stage3D intends to increase overall reach for the Stage3D APIs to older commonly available GPUs. This allows more players to run your game with GPU rendering (as opposed to Software Rendering, which is a magnitude slower). This is especially useful for browser games.

When you start up Starling with the “auto” profile, it will pick the best available profile for the current hardware automatically. So you don't need to do anything special to support constrained mode. This makes it possible that about 95% of your players will be able to run your game with GPU support via the Flash Plugin.

// Just use the default constructor.
starling = new Starling(Game, stage);

Constrained mode has several limitations, though. If you use the standard Starling components, this is not a problem (they all adhere to these limitations); but when you create your own shaders, you might want to keep them compatible with the constrained profile.

The constrained profile has the following limitations:

• Limited to 64 ALU and 32 texture instructions per shader.
• Only 4 texture read indirections per shader.
• Limited to a smaller amount of constants/varying/temps per shader.
• No support for predicate register. This affects sln/sge/seq/sne and needs to be replaced with compound mov/cmp instructions (this is done under the hood at the cost of using more instruction slots).
• As on mobile, the conventional Flash stage will only be updated when you call “present()” on the stage3D context.
• Only one Stage3D object can be active at a time (like on mobile).
• The viewPort of the Stage3D instance needs to be within the stage bounds. (Starling tries to hide this limitation from you, though.)