| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ 3.4ms (draw), PC 2.97ms (Region) + 0.36ms (draw) (GOOD)
Performance update from commit 607eb99b9cad227dd7be6d149c6b6cf57d060c35
(Note: There I mentioned the total duration for 20 frames, not per frame)
A Performance @ 2.4.0 with 119,787 vertices:
- doc/curve/tests/perf00/rpi4_old.log
- RaspiPi4 57.20ms (Region) + 23.4ms (draw)
B Performance @ commit 607eb99b9cad227dd7be6d149c6b6cf57d060c35 with 81,092 vertices:
- doc/curve/tests/perf01/rpi4_7.log + doc/curve/tests/perf01/pc_7.log
- RaspiPi4 11.76ms (Region) + 3.5ms (draw), PC 3.4ms (Region) + 0.35ms (draw)
C Now with 81,092 vertices (and a slight bigger buffer due to 'count' pre-size):
- doc/curve/tests/perf02/rpi4_10.log + doc/curve/tests/perf02/pc_10.log
- RaspiPi4 10.25ms (Region) + 3.4ms (draw), PC 2.97ms (Region) + 0.36ms (draw)
Hence we enhanced performance from A -> C reasonably.
Most important is that neither 'Flight Recorder' not 'Visual VM' could identify
Region.addOutlineShape()'s triangulation nor vertices compounding to be
significant throttle.
After further triangulation bugfixes (delauny tesselation),
we might analyze performance of this method further.
Enhancements of VBO GLArrayData data management
where Region.addOutlineShape() finally we pushes the data into the VBO
helped to remove certain overhead.
Mostly the buffer-size enhancements including API-hooks to count the required vertices & indices
to issue Region.setBufferCapacity() helped to ease the GC.
|
