Am Mittwoch, den 13.07.2011, 14:07 +0200 schrieb Stefan Eilemann
<[email protected]>:
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.
Ahh, please say that again.
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.
I did not say anything in that direction.
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
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.
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.
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.
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.
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?
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.
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).
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).
To be honest with you, I am losing motivation.
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.
Configurable via config file (dynamic, in addition) or configurable via
compile flag (static, explicitely)?
Currently, the used windowing toolkit can be influenced by a config
file.
How so?
I might be wrong here. I remember that we have a factory that creates
windows based on a dynamic value. In theory, we can choose between AGL,
GLX and WGL at runtime. If there is no ue case for that, we could get
rid of the factory.
Forgive my ignorance, but is there a use-case for that?
I don't see one.
Good.
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?
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.
cheers, Daniel
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
