Hello, On 13. Jul 2011, at 16:12, Daniel Pfeifer wrote:
>> What you are missing is the bigger picture which will look like: >> >> - Visualization resources (GPU's, display segments of a larger >> installation, etc.) are configured locally on each computer and >> announced on the network >> - The application may query and allocate views on displays (canvases) >> - The application may create local views (windows, your use case) >> - Equalizer (server) will discover and auto-configure the usage of >> scalability resources based on application requests/hints > > Some of these features operate in the backend (eg. load balancing). These > features are the reason why we want Equalizer in the first place. > Other features are rather application specific (window creation). Not > implementing them as part of a parallel rendering framework might turn out as > an advantage: > > - Application developers who need it have the flexibility to implement it the > way they want. > - Application developers who do not need it do not even have to think about > it. > - As a library developer, you do not have to implement it. You are correct (there, I said it!) in the case of my item 3. For item 2 and 4 the application does not and should not know how many windows have to be configured where. Similarly you do not know how many threads a CUDA kernel will use at execution time, and on how many cores they are scheduled. > I perceive the current system as dynamic: the complete architecture of nodes, > windows, canvases is constrcuted based on a config file that is parsed at > runtime. ...because it's a dynamic environment. > I was describing two different things in the above paragraph: > 1) Equalizer as backend for an exisiting application. > 2) Controlling the amount of windows dynamically. > > RTT is doing 1) with Qt and eqPly is doing 2) without Qt, right? RTT is doing 1 and 2. > On top of a library that provides 1) only, it is easy to build a layer that > supports 2). > My point is that 2) should be factored out. Someone who needs 1) should not > need to struggle with 2). 2) should be possible for *destination view* only. Source channels (which need a window too) are dynamic and not app-controlled. >>> The next topic is Qt. Last year, you wrote in the Equalizer Roadmap that >>> Sequel should provide Qt widgets. How did you mean that, 'explicitely' or >>> 'in addition'? >> >> By default on the application node, but configurable. > > Configurable via config file (dynamic, in addition) or configurable via > compile flag (static, explicitely)? Configurable programmatically. > The issue with the current approach is that Equalizer does not rely on the > application to provide a windowing system. > > Look, when I want a function to be called, I call it. When I do not want a > function to be called, I just do not call it. I do not want to write any code > just to intercept some default implementation. Sometimes less is more. Simple things should be simple, and complex possible. GLUT implements the first paragraph only, you propose the second. Eq does both. In any case you would have to provide a method to create a window on request - so what's the issue if this method has a default implementation? Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
