I’ve just committed to trunk some hooks for application profiling. For a long time, I’ve missed in JME the ability to see where the time in a particular frame is going. In a previous discussion (that I can no longer find a link to) on here I mentioned that I intended to do something about this in a more general way… that was probably a year ago or more now. I’ve tried to incorporate all of the ‘desirements’ mentioned in that thread. My notes were thready, though.
This is still a bit experimental but it’s functional and I’ve added a basic profiler visualization. So much more is possible if an application wants to get more detailed information.
The basic entry point is the AppProfiler interface. This has two methods: appStep(AppStep step) and vpStep(VpStep step, ViewPort vp, Bucket bucket).
appStep() is called for the larger application-level parts of a frame. vpStep() is called for viewport/bucket sub-parts of a frame. An AppProfiler implementation can choose to pay attention to or ignore whatever it likes.
By default, the application’s AppProfiler is set to null and effectively amounts to a no-op. When set, each of those methods is called at the appropriate time with the different AppStep or VpStep enum values. In this way, a profiler implementation could even just collect timings for a single ViewPort if it wanted.
Those classes are all in com.jme3.profiler.
In addition to those classes and the necessary hooks in Application, SimpleApplication, and RenderManager, I’ve also added a BasicProfiler and BasicProfilerState to manage it. This profiler implementation tracks application-wide frame timings for ‘update’ and ‘render’ and displays them as a continuously updating bar graph.
Each column represents a single frame. Yellow indicates the portion of the frame that was spent in ‘update’, ie: all non render stuff: enqueued tasks, state updates, control updates, etc… The cyan portion indicates the portion of the frame spent in rendering. The green area represents 16.666… milliseconds, ie: timings that fall outside of that area would drop a frame if 60 FPS is the target. The red area ends at 33.3333… milliseconds though the bar graph is free to draw outside of that range.
To use (if you are building from trunk), simply attach the BasicProfileState to your application. F6 will then toggle on/off the display.
Note: if vsync is on then the synching is part of the cyan area and so pretty much all frames looked maxed out. For meaningful timings it is necessary to leave vsynch off… unless you are just curious where you are dropping frames or spending a lot of ‘update’ time.