How do I define macros while building using makepanda?
e.g. to have a #define THREADED_PIPELINE (used in graphicsEngine.cxx)
You’ll have to edit makepanda. Either add it to the big DTOOL_CONFIG list, or stuff this line somewhere:
DefSymbol("ALWAYS", "THREADED_PIPELINE", "")Actually, THREADED_PIPELINE is not to be defined by the user. It is defined in selectThreadImpl.h, if both DO_PIPELINING and HAVE_THREADS or defined.
So you’ll need to define those in makepanda. You might also want to disable SIMPLE_THREADS (set it to UNDEF) to get true threading.
If you’re using latest CVS’ makepanda, you can easily do this without editing the makepanda script, by using the --override command-line option (see makepanda --help for more details)
Be very careful when enabling DO_PIPELINING (and THREADED_PIPELINE). The pipelining support in Panda is incomplete and experimental. It is likely to fail to compile, crash, deadlock, or destroy your favorite childhood toy.
David
so in reference to this thread what does this imply?
Once it becomes possible to have separate window and draw threads and we ensure that window::process_events() happens in the window thread (the problem of openGL context not re-bindable as mentioned here notwithstanding)the problem as mentioned in the other topic should be solved ?
Right, pipelining support, once it is complete, might partially solve the problem referenced there, because it will delegate rendering to a child thread. But it’s really the main thread that is the most important thing not to block, not the draw thread (it’s the main thread that’s responsible for advancing the frame); so the best solution would be to move just the GetMessage() loop into its own thread. Full pipelining support is a much bigger hammer that is designed to solve a different, unrelated problem.
But moving GetMessage() into its own thread poses its own set of problems. It might be possible, but the first requirement is that Panda is compiled to support true threads, instead of its default simple_thread model, which means you need to disable SIMPLE_THREADS in makepanda.
Beyond that, we’d have to have special code in display and/or windisplay to spawn a thread and set it up as the window_thread, and make the appropriate Windows calls to move the window’s event queue into a new thread. The existing window_thread code in Panda may have to be examined for cruft, as well; it hasn’t been touched quite in a while and I have my doubts about its correctness.
All of this would require some familiarity with the threading mechanism employed by the GraphicsEngine class.
Another approach would be to use a timer, as you describe in the other post, rather than using a sub-thread. This might be the easier approach (and wouldn’t require enabling threading in the build, which is overall expensive). Still, even this would require some retrofitting within Panda, because the task loop is not designed to be reentrant; it would mean we would have to pull the igloop task out of the task chain, and have it be called implicitly by the TaskManager between epochs. This has implications for applications that wish to spawn tasks with sort orders relative to the igloop task, though, so proceeding with caution here is also advised.
Not that I want to discourage you from making improvements to Panda, far from it. But offhand, I’d say you’ve picked a particularly knotty problem to start with. 
David