CID 11834: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _tickLastUpdated is not initialized in this constructor nor in any functions that it calls.
Non-static class member _tmpText is not initialized in this constructor nor in any functions that it calls.
CID 11833: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _tmpText is not initialized in this constructor nor in any functions that it calls.
Also I've done the osguserstats example. I've kept the "toy example" that was in the modified osgviewer.cpp I had sent you, because they show different uses of custom stats lines (a value displayed directly, a value without bars and a value with bars and graph). I also added a function and a thread that will sleep for a given number of milliseconds and record this time in the stats. I think it clearly shows how to record the time some processing takes and add that to the stats graph, whether the processing takes place on the same thread as the viewer or on another thread.
BTW, feel free to modify the colors I've given to each user stats line... I'm not very artistic. :-)
I've also added more doc comments to the addUserStats() method in ViewerEventHandlers, so hopefully the arguments are clear and the way to get the results you want is also clear. Maybe I went overboard, but the function makes some assumptions that may not be obvious and has many arguments, so I preferred to be explicit."
The user calls statsHandler->addUserStatsLine() providing:
- the label they want for that line in the graph
- the text and bar colors they want in the graph
- the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed.
Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph.
They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars.
Along the way I cleaned up the existing code a bit:
* Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats().
* I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning.
* The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input.
"
- The text and dark background rectangles are now correctly placed, and
slightly resized here and there.
- All counters (vertices, etc) now use a fixed formatting with 0 digits
precision, to prevent the text from being shown in scientific notation
when the number get large (e.g. 6.34344e+6). I tested with a scene
containing roughly 4 million vertices, to make sure its stats would
display correctly.
I also made slight changes to osgcompositeviewer (attached) to aid in
testing the stats display, specifically displaying of camera and view
names."
The graph is displayed "under" (behind) the normal bar chart you get when you press 's' twice. It doesn't hide the normal stats, you can still read them without any trouble, and that way, it doesn't take any more screen space. It starts from the left, and will scroll left when there is enough data to fill the screen width. The graph lines have the same colors we're used to (except I made the event color a bit bluer, so it's not exactly the same as the update color). A screen shot is attached.
The lines get a bit confused when they're all overlapping at the bottom of the graph, but I think that's the least of our concerns (if they're all at the bottom of the graph - except FPS of course - then great!).
The only thing I'm not very keen about is that to make things simple, I clamp the values to a given maximum. Right now, the maximums I have set are:
* Frame rate: 100 fps (people have 60, 75, 85Hz refresh rates, so there's no one right value, but I think 100 is OK)
* Stats: 0.016 seconds (what you need to get 60Hz minimum)
This could be changed so that the scale of the graph changes according to the maximum value in the last screenful of the graph instead of clamping values. We would then need to display the scale for each value on the side of the graph, because if the scale changes, you need to know what it is at this moment.
I tried to make things easy to change, so for example if you don't like that the graph is in the same space as the normal stats bars, it's easy to move it anywhere else, and make it have other dimensions. The maximums and colors are also easy to change.
The impact on performance should be minimal, since it's one vertex per graph line that's added per frame, and vertices are removed when they scroll off the screen, so you'll never have more than say 1280 * (3 + ncameras) vertices on the screen at one time. No polygons, I used line strips. The scrolling is done with a MatrixTransform."
This code will add two extra statistics options:
-Camera scene statistics, stats for the scene after culling (updated at 10 Hz)
-View scene statistics, stats for the complete scene (updated at 5 Hz)
Each camera and each view will expand the statistics to the right.
I also added the requests and objects to compile of the databasepager to the databasepager statistics.""
