Hi Daniel, all, On 12. Jul 2011, at 12:04, Daniel Pfeifer wrote:
>> The goal: >> 1. allow Qt to create a GL (we use QGLWidget) >> 2. try to keep things isolated into ctors and dtors so current coding >> styles are mostly unaltered > > This is _exactly_ the use-case that I would expect from most prospective > clients. You are correct. > This is also the reason why it is so much easier to use IceT rather than > Equalizer. Apples and oranges. This is like saying that a BSD socket is easier than boost::asio. > Read that goal number one again, but generalize the windowing toolkit: "allow > ... to create a GL". This statement is correct, and possible today. It is not easy to do, which is wrong and needs to be fixed. 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 The current system perceived as static by you is a stepping stone in that direction. The file format will eventually be optional, but still be used as a transient server state to drive the current configuration. > Most clients seem to have an exisiting application (consisting of one or more > windows) and want to use parallel rendering in the backend. To them (myself > included), a parallel rendering framework that does not simply render into > windows when told to do so, simply does not fulfill the requirements. > Controlling the amount of windows dynamically is a nice feature and I am > confident there are enough use-cases for that. RTT is doing exactly that today, with Qt and Equalizer. eqPly is doing this without Qt when you press 'p' or 'a' (minus the bug I've just fixed). As said above, the how in this procedure is not good. > But building such a dynamic system on top of a simple static one is > definitely possible. The other way round it is not possible. Ack. I'm not sure what your point is here. > The current approach (Equalizer is responsible for creating windows based on > a config file) locks out many clients that would prefer a static solution (I > create the windows and tell Equalizer to parallelize rendering). What is missing today is the ease of use (see above) and scalability auto-configuration. The latter is partly understood and partly a research topic (hint). > Providing a static solution, and a dynamic one built on top of that would > allow both static and dynamic use-cases. > > Having said that, I think we should discuss whether (simple) Sequel really > should be build on top of (dynamic) Equalizer. In this step you lost me. > 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. > Currently, the used windowing toolkit can be influenced by a config file. How so? > Forgive my ignorance, but is there a use-case for that? I don't see one. > Maybe it would be easier to have "Eq for Windows" with WGL, "Eq for Mac" with > AGL or cocoa, and Sequel for Qt? If there really is a use-case, we could > provide a "multi-toolkit Eq", that is built on top of some of the specific > ones. It is a use case when you want to use the same executable to run with Qt on the desktop and with 'native' windowing on a powerwall or scalability nodes. What is the issue with the current approach of letting the application provide the window system glue and providing 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
