Optimizing render performance¶
There's no silver bullet. Typical bottlenecks:
- Fillrate. Drawing many large, overlapping particles is slow. On a GTX 2070 a 1080p buffer can be overdrawn roughly 100 times before you hit the limit.
- RenderTarget sizes. Start with your target resolution (e.g. 1080p) in the output-window resolution selector. The cost is often smaller than you expect.
- Sample counts. Image operators like
[Blur]sample the image many times to produce a smooth gradient. 50 samples is usually fine; you often need fewer. Above 200, justify each sample. - Multisampling. The default is 4× MSAA. Disabling it on a complex scene (millions of lines) can have a large effect.
- Too many RenderTargets. Where possible, reduce the number of "magenta" ops and replace them with "cyan" command ops.
- Animating buffer sizes. Changing the size of a buffer is much slower than changing its content. Under 100,000 elements is fine; above that, resizes can dominate frame time.
- Draw calls. Rendering objects via individual draw calls (e.g. with
[Loop]) is extremely slow. Loop counts above ~1000 iterations are unlikely to run in real time. - Multiple displays. Your display setup can strongly affect performance:
- Make sure every display uses the same scaling factor in Windows "Display" settings. Set a custom scale factor if in doubt.
- Keep windows from overlapping display boundaries.
- Sometimes restarting the machine is needed to get this to stick.
Don't assume — measure. Graphics pipelines are complex and highly optimized. A few myths:
- The difference between power-of-two and arbitrary texture sizes (256×256 vs 100×100) is usually negligible.
- Generating mipmaps is very cheap.
Tips¶
- Disable frame-sync by clicking the performance graph in the application header.
- Disable parts of your render graph and compare the impact of each.
- Showing complex graphs in the graph window has its own performance cost.