Cull GUI elements not in scissor bounds

[sarbes]

Description

With the PR, we check if the GUI element we want to render is in bounds of the current scissor region. If not, we can avoid the related geometry setup and drawcall(s).

Motivation and context

Drawcalls are expensive. Our current geometry processing is expensive. Both can be avoided for elements outside of the scissor box we want to render to. This is especially important if we apply our "Cost Reduction" (2) dirty region algorithm. But also our "Union" algorithm, as well as full screen rendering will profit from out-of-bounds culling.

Without it, the cost reduction option is absolutely not viable, as it submits all drawcalls for each region, instead of only the ones needed for each region.

I'm guesstimating that the cost of it will be amortized by avoiding one drawcall.

How has this been tested?

Running various skins, I couldn't see any missing UI elements.

What is the effect on users?

Less CPU and GPU utilization. How much depends on the system, skin, and DR scheme.

Screenshots (if appropriate):

In this example, the "Cost Reduction" algorithm is active. You can see a "2" being rendered in a region (marked by the black/white scissor outline). For this region, only a glClear() and one glDrawElements() is submitted. Without the patch, all drawcalls (>30) would be submitted for each region rendered.

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[CrystalP]

Would that help the ControlGroupList that always renders all children, even when outside its area?

oh and... great idea!

[sarbes]

Would that help the ControlGroupList that always renders all children, even when outside its area?

oh and... great idea!

I wanted to be on the safe side. I'm not even sure if elements outside of a group boundary are legal.

[CrystalP]

I wanted to be on the safe side. I'm not even sure if elements outside of a group boundary are legal.

Maybe not, but I was thinking about the case when there are more items in the grouplist than what can be displayed at once given the group boundaries. In that situation it displays what fits and provides a scrollbar. The rest of the children is clipped but still rendered if I remember correctly from when I was writing my PR about page up/down in grouplists.

[sarbes]

TY!