[hinrikg]

Summary

Adds Tr2Sprite2dEffect, a leaf sprite that draws one Tr2Effect over its rect, so a UI element can have a custom shader at a low per-element cost.

The problem

A sprite's look is otherwise fixed by the uber shader. The only way to draw a custom shader over a UI element has been a Tr2Sprite2dRenderJob per element, which runs its job outside the scene's batch: the scene flushes, leaves managed rendering, swaps the depth stencil, glow target and viewport around the job, and restores its states afterwards. The job also knows nothing of where its sprite is on screen or how opaque its ancestors are, so the caller has to work that out every frame and place a viewport. And since a viewport is axis-aligned and the glow target is unbound inside a job, the effect neither rotates with its ancestors nor writes glow.

How it works

 Tr2Sprite2dScene::Render
   GatherSprites, in tree order
-    Tr2Sprite2dRenderJob::GatherSprites
-      IssueDrawCall                 # flush the batch
-      RunJobHelper                  # state bracket around the job
-        job->Run                    # set viewport, render effect
-      restore states, vertex declaration, textures, index buffer
+    Tr2Sprite2dEffect::GatherSprites
+      build the quad's 4 vertices
+      RenderTriangleVerts( effect, verts )
+        IssueDrawCall               # flush the batch
+        batch the 4 vertices        # transform index and clip rect like any sprite
+        IssueDrawCall               # effect in place of the uber shader

Tr2Sprite2dEffect sends its quad through the scene's batched vertex path like any sprite's, so it is clipped, transformed, captured into display lists and drawn in 3D as other sprites are, with no per-frame work outside the scene. The effect replaces the uber shader for that one draw call, with the uber shader's vertex layout and constants. The sprite fills the vertex fields for its own purpose: texcoord 0 runs 0 to 1 over the quad, texcoord 1 holds the quad's size, and the sprite's color, glowBrightness and spriteTarget ride in the vertices. An override effect gets none of the scene's textures, since the scene would bind them over the effect's own.

Each effect sprite is still a draw call of its own, which breaks the scene's batch. That is the whole of its cost. A plain batch break is also cheaper than a render job's interruption, since a job saves and restores the scene's render state as well.

Performance

Measured in the client with a few hundred custom-shader sprites spread over different branches of a nested UI tree, against the same sprites drawn as render jobs placed from Python: the effect sprite costs about 10x less CPU per sprite. Even in the best case for the render-job path, with every sprite under one shared ancestor chain so its placement work is shared too, the effect sprite is still about 2.5x cheaper. What remains of the effect sprite's cost is its separate draw call; GPU time is at the noise floor on both paths.