In the previous article on 3D point cloud for FMX, systematic memory copy when drawing primitives came out as #1 bottleneck in FMX performance when rendering millions of points.
But was it just a false positive ?
I hacked FMXU.Context.DX11 to eliminate the memory copies… in the most hacky way, don’t ask for code it’s not re-useable 🙂
And the rendering framerate for the Villa Dondi (4.6 millions quads) jumps from 24 FPS to about 59 FPS. This more than doubled the performance!
So quite obviously, there is a lot of potential here. But since the TDX11Context class is implemented (as an implementation class), there is indeed no way to introduce the change by sub-classing.
This leaves probably just two options:
- releasing a modified FMX.Context.DX11. To avoid copyright issues, this means releasing the changes as a diff. This would be fragile and edgy (if the diff reveals copyrighted code).
- doing a clean room re-implementation of FMX.Context.DX11
Option 2 is more involved, but the unit isn’t that big at 1764 LoCs. And there is a lot of redundancy. A reimplementation with no new functionality would probably be around 1000 LoCs.
A somewhat more problematic aspect would be TContext3D (the higher level ancestor, that lives in FMX.Types3D), which takes TVertexBuffer and TIndexBuffer parameters.
Ideally those two classes would be perfect to tag a buffer as being static or gpu-memory. But, alas, while their constructor is virtual, their SetLength method is not virtual. And not much about them is virtual, this will have be danced around..
This is another can of worms for a fully integrated expansion of TDX11Context. Gotchas and a degree clunkiness to expose support for static/gpu buffers will be inevitable. We may have to “burn” that one class helper…
On the plus side, after a quick look at FMX.Context.GLES & FMX.Context.Metal, all the various current FMX context implementations use temporary buffers when drawing primitives. Thus, all platforms would benefit from having built-in support for more static array buffers!
