panda startup time (again)

I’m on a holy quest to make panda’s startup instantaneous. A long time ago I played with DX and I miss the instantaneous startup of things, also I have noticed that some engines like Irrlicht have near to instantaneous startup times, so there’s no reason why Panda shouldn’t (at least with DX and tiny, unfortunately GL always initializates slowly on Windows). In my PC, panda (cvs version) takes by default 0.4 seconds with tiny, 0.6 with DX and 0.8 with GL. Removing what I explain below I got it to 0.09 with tiny, 0.17 with DX and 0.4 with GL.

David, you removed some cpu detection code in WinGraphicsPipe some time ago when I posted here complaining that panda started in 2 seconds, and today I built the CVS version for the first time and I immediately noticed that it wasn’t as fast as my own version which had more things removed. I’ve been profiling everything and I’ve located a couple of bottlenecks. I’m curious if these are also cases of stuff that isn’t really needed.

First bottleneck, happens with any renderer if you have DX support built-in. It’s in winGraphicsPipe:

if (state == false && dx9_display_information (display_search_parameters_dx9, _display_information)) {

This takes 0.4 seconds in my pc. Which is funny because this call is inside a #ifdef HAVE_DX9 block, which means that panda is been working fine without it whenever somebody uses GL and Tiny without DX support built-in. What does this do? Is it safe to remove? If so, would a patch to make it optional be welcome? I removed it and everything seems fine (Disclaimer: I can’t test it in full-screen because for some reason Panda never worked for me on full-screen on this PC).

Second bottleneck, on wdxGraphicsPipe9.cxx, 0.2 seconds. Happens when using DX9.

hr = pDD->GetDeviceIdentifier(pDX7DeviceID, 0x0);

It seems like too little, but at this point, those 0.2 seconds would make it as snappy to start as Irrlicht. It’s inside this function:

//     Function: wdxGraphicsPipe9::find_all_card_memavails
//       Access: Private
//  Description: Uses DX7 calls to determine how much video memory is
//               available for each video adapter in the system.
//               Returns true on success, false on failure.

Multiple video adapters + DX7, sounds like stuff I don’t need, and I didn’t find something like this in other engines. Again, what does this do? Is it safe to remove? If so, would a patch to make it optional be welcome? I replaced the function with a “return true” and everything works fine.

Third one is in graphicsEngine.cxx:

_app.do_windows(this, current_thread);

I just report it for the sake of it, because this is the GL/DX initialization and there’s nothing to do about it, I guess. For the record, it takes 0.15 seconds in DX, 0.4 seconds in OpenGL and 0.001 with tiny (I’m using Windows 7).

Hope you find some of this interesting and we can have some improvement in this sense for 1.7.

Hmm, this is indeed interesting. I freely admit I don’t know what some of these functions do; some of them might be old cruft, and some of them might be potentially-useful data gathering. I’ll look into it more carefully.