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."
To facilitate this possibility I have added a template copy constructor and a template assignment operator. These work for safe conversions like those in my previous example, but fail as desired for non-safe conversions since the template instantiation fails during the raw pointer copy/assignment.
The lack of this facility has appreciably handicapped development of generic algorithms applied to the scene graph, and I believe that this alteration will be welcomed by most of the community. If there are issues with antiquated compilers not supporting template member functions then perhaps a small piece of conditional compilation is in order.
I have made the change using the latest release version (2.6) as the base. The full file is attached.
I have not tested building the osg wrappers and the script binding code. I have tested the legal and illegal conversions of both copying and assignment to ensure that behave as expected on MSVC7.1, MSVC8, MSVC9, GCC 4.3."
Quicktime supports only files with 3/4-channels rgba-files and not 1/2-channels rgb-files.
This submission is from Tatsuhiro Nishioka, here's his original quote:
When FlightGear crashes, the error message
"GraphicsImportGetNaturalBounds failed" shows up. By adding printf
debug, I found the error was -8969: codecBadDataErr when loading a
gray-scaled (2 channels) rgba files even though the file can be loaded
with Gimp and osgViewer properly.
So I made an investigation on this problem and found an interesting
thing. This error occurs only when non-rgb files are loaded before rgb
files. The reason is that rgba files can be handled by both
osgdb_rgb.so and osgdb_qt.so, but the error happens only when
osgdb_qt.so try to load a gray-scaled rgba file.
When a program is about to load an rgba file, osgdb_rgb.so is loaded
and it handles the rgba file properly. In contrast, when a gray-scaled
rgb file is being loaded after a non-rgb file (say png) is already
loaded by osgdb_qt.so, osgdb_qt.so tries to load the file instead of
osgdb_rgb, which causes the error above.
Anyway, the bad thing is that QuickTime cannot handle gray-scaled rgb
files properly. The solution for this is not to let osgdb_qt handle
rgb files since osgdb_rgb can handle these properly.
"
