Hi Harris, On 1. May 2012, at 22:56, cpapado wrote:
> However, I've come across an issue. In our framework, I've subclassed > eq::Window and added a bunch of code for doing (among other things) scene > loads. Generally speaking, the windows on which the composition happens > should not need any of the additional functionality that I have added to the > eq::Window class. What would be the best way to differentiate between an > actual backbuffer rendering surface and visible window in the case described > above? Is there some way to reach the window name defined in the config file > from inside eq::Window? Window::getName() is always a last-resort hack to do specializations like you describe. I however always try to find another way which doesn't rely on special configs. Configs are supposed to be generic, and will become more and more auto-generated. > Is there some other accepted eq coding practice that > I am not aware of? What has emerged as a pattern is to delay rendering-specific initialization to the first Channel::frameDraw which needs it. This also works nicely with DB compounds, where you only want to load the partial data needed by a given resource. Even better, if feasible, is to do the initialization in an asynchronous thread and render a 'loading...' in the channel while this is going on. This keeps the application responsive. HTH, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
