We have implemented a simple approach to user interface batching to improve performance of UI rendering:
-
You can easily activate it by
Container.UserInterfaceBatching := true
. SeeTCastleContainer.UserInterfaceBatching
API docs. -
We also added a way to observe whether/how much do you gain. Look at class variable
TDrawableImage.Statistics
information. In particular useTDrawableImage.Statistics.ToString
, orTDrawableImage.Statistics.DrawCalls
,TDrawableImage.Statistics.ImageDraws
. Display them in any way (e.g. on some label). -
There’s simple example examples/user_interface/ui_batching/ that shows how to use it. It also shows how it decreases draw calls from 57 to 21.
-
The
TCastleContainer.UserInterfaceBatching
docs do try to “manage the expectations” and outline what to expect from it.The existing algorithm is simple. It can be beneficial — it’s nice if you have lots of
TCastleLabel
orTCastleImageControl
with same image, rendered one after another.But it can also be pretty worthless. This approach helps with rendering some easy arrangements of UIs, where underneath we render a subset of the same image many times. It will not help if we keep changing images, e.g. when rendering buttons’ backgrounds and captions.
Moreover, note that usual applications do not have a bottleneck at UI draw calls rendering. Probably, stuff like 3D and 2D game world is your main concern, not UI, and not UI draw calls 🙂 Remember to optimize smartly, where it matters.
Try it out, let us know how it performs in your project!
Do you like what we do? Please support us on Patreon!
Start the discussion at Castle Game Engine Forum