Windowing(DirectX/OpenGL)

Can OpenGL or DirectX be also used to create windows in multiple
sessions(a general purpose windowing framework)?

Since I am a rookie, I am afraid I might not get to
frame my question appropriately.

The intent is to forego having to use the Win32 API
to do anything but the most minimal of Window functions.

What would happen if multiple threads needed multiple windows?
Do DirectX or/and understand multi-threading? Do they need to?
I presume they would not if the OS invokes callbacks or even
a signal of some kind(as simple as saying redraw your window).

Will be equally nice if experts are able to help on
performance(speed/space)
issues.

mp2sleep@hotmail.com wrote:

> Can OpenGL or DirectX be also used to create windows in
> multiple sessions(a general purpose windowing framework)?

No, and no.

> Since I am a rookie, I am afraid I might not get to
> frame my question appropriately.

OpenGL and DirectX Graphics are rendering APIs. They do not
windowing.

> The intent is to forego having to use the Win32 API
> to do anything but the most minimal of Window functions.

There are wrapper libraries for OpenGL. Either use one of the
Toolkits with OpenGL support or use one of the OpenGL
frameworks.

> What would happen if multiple threads needed multiple windows?

Multiple threads with each having it's own window is no problem
at all. The problems arise, when the threads are interfering.

OpenGL is thread safe, as it has no callbacks. Just make a own
rendering context for each thread, share the display lists of
them and you're fine. However you should avoid that multiple
threads are rendering simultanously into the samw window, which
can lead to strange effects. A mutex would be the right thing to
choose. The best is however not to cross render between threads
into the _same_ window at all.

--
Wolfgang Draxinger

> OpenGL and DirectX Graphics are rendering APIs. They do not
> windowing.
>
> > The intent is to forego having to use the Win32 API
> > to do anything but the most minimal of Window functions.
>
> There are wrapper libraries for OpenGL. Either use one of the
> Toolkits with OpenGL support or use one of the OpenGL
> frameworks.
>

Just so that syntactic sugar is differentiated from feature
availability, I want to know if a Toolkit designer would be
able to provide a Windowing facility by just using OpenGL
internally.

It is ok that OpenGL is "low-level", I presume line-drawing
itself shall be enough to implement Windowing.

What kind of performance hit or saving would one incur when
compared to using the Win32 API?

I would be happy with any one of OpenGL or DirectX.

> OpenGL and DirectX Graphics are rendering APIs. They do not
> windowing.
>
> > The intent is to forego having to use the Win32 API
> > to do anything but the most minimal of Window functions.
>
> There are wrapper libraries for OpenGL. Either use one of the
> Toolkits with OpenGL support or use one of the OpenGL
> frameworks.
>

Just so that syntactic sugar is differentiated from feature
availability, I want to know if a Toolkit designer would be
able to provide a Windowing facility by just using OpenGL
internally.

It is ok that OpenGL is "low-level", I presume line-drawing
itself shall be enough to implement Windowing.

What kind of performance hit or saving would one incur when
compared to using the Win32 API?

I would be happy with any one of OpenGL or DirectX.

> OpenGL and DirectX Graphics are rendering APIs. They do not
> windowing.
>
> > The intent is to forego having to use the Win32 API
> > to do anything but the most minimal of Window functions.
>
> There are wrapper libraries for OpenGL. Either use one of the
> Toolkits with OpenGL support or use one of the OpenGL
> frameworks.
>

Just so that syntactic sugar is differentiated from feature
availability, I want to know if a Toolkit designer would be
able to provide a Windowing facility by just using OpenGL
internally.

It is ok that OpenGL is "low-level", I presume line-drawing
itself shall be enough to implement Windowing.

What kind of performance hit or saving would one incur when
compared to using the Win32 API?

I would be happy with any one of OpenGL or DirectX.

mp2sleep@hotmail.com wrote:

> Just so that syntactic sugar is differentiated from feature
> availability, I want to know if a Toolkit designer would be
> able to provide a Windowing facility by just using OpenGL
> internally.

No.

> It is ok that OpenGL is "low-level", I presume line-drawing
> itself shall be enough to implement Windowing.

You're forgetting input handling, processing events from the
windowing system, etc. You can of course make a full screen
window and therein draw windows yourself (actually that is what
I'm doing in my engine's modeller) - but that is only 10% OpenGL
and the rest is implementing the whole windowing (user
interactin, input, events) stuff.

> What kind of performance hit or saving would one incur when
> compared to using the Win32 API?

Still you need the Win32 API (or DirectInput) to process the
actual input events. You can't circumvent this. But the window
your application is running in can only be created with the
functions of the windowing system (Win32, Xlib etc.)
(Theoretically you could circumvent the use of Xlib in a X11
environment, since this is a networked windowing system - so be
doing the whole communication yourself you could emulate Xlib;
however I don't see a reason, why someone would be so
masochistic to do this. However even such a DIY Xlib would still
have to implement the X protocol so you're still bound by the
used windowing system).

Also remember, that the Win32 windowing is done with high
priority in the operating system. Doing such stuff in the
application will be less performant in Win32 conditions (in X11
it doesn't matter, as it's done in userspace anyway). In my
modeller I'm doing it all myself, because it's _portable_ and
always looks the same, regardless of the used environment. And
as I'm using a own, uncommon UI scheme - with a very steep
learning curve (parts of the UI are inspired by blender, SGI's
Motif variant and a few other toolkits - I just took the best of
every concept and merged it) - this doesn't matter.

> I would be happy with any one of OpenGL or DirectX.

Rendering APIs are doing what the name suggests: They're
rendering. Well DirectX has some input stuff, but still you need
a window for your application and that can only be done with the
functions of your windowing system.

If your problem is portability: Use one of the wrapper libs.
GLUT, SDL mainly for pure rendering applications. Or a real
Toolkit wich OpenGL support: GTK, Qt, FLTK, wxWidgets. They're
all cross plattform and with a proper written code they can be
recompiled for every plattform without glitches.

--
Wolfgang Draxinger

mp2sleep@hotmail.com wrote:

> Just so that syntactic sugar is differentiated from feature
> availability, I want to know if a Toolkit designer would be
> able to provide a Windowing facility by just using OpenGL
> internally.

No.

> It is ok that OpenGL is "low-level", I presume line-drawing
> itself shall be enough to implement Windowing.

You're forgetting input handling, processing events from the
windowing system, etc. You can of course make a full screen
window and therein draw windows yourself (actually that is what
I'm doing in my engine's modeller) - but that is only 10% OpenGL
and the rest is implementing the whole windowing (user
interactin, input, events) stuff.

> What kind of performance hit or saving would one incur when
> compared to using the Win32 API?

Still you need the Win32 API (or DirectInput) to process the
actual input events. You can't circumvent this. But the window
your application is running in can only be created with the
functions of the windowing system (Win32, Xlib etc.)
(Theoretically you could circumvent the use of Xlib in a X11
environment, since this is a networked windowing system - so be
doing the whole communication yourself you could emulate Xlib;
however I don't see a reason, why someone would be so
masochistic to do this. However even such a DIY Xlib would still
have to implement the X protocol so you're still bound by the
used windowing system).

Also remember, that the Win32 windowing is done with high
priority in the operating system. Doing such stuff in the
application will be less performant in Win32 conditions (in X11
it doesn't matter, as it's done in userspace anyway). In my
modeller I'm doing it all myself, because it's _portable_ and
always looks the same, regardless of the used environment. And
as I'm using a own, uncommon UI scheme - with a very steep
learning curve (parts of the UI are inspired by blender, SGI's
Motif variant and a few other toolkits - I just took the best of
every concept and merged it) - this doesn't matter.

> I would be happy with any one of OpenGL or DirectX.

Rendering APIs are doing what the name suggests: They're
rendering. Well DirectX has some input stuff, but still you need
a window for your application and that can only be done with the
functions of your windowing system.

If your problem is portability: Use one of the wrapper libs.
GLUT, SDL mainly for pure rendering applications. Or a real
Toolkit wich OpenGL support: GTK, Qt, FLTK, wxWidgets. They're
all cross plattform and with a proper written code they can be
recompiled for every plattform without glitches.

--
Wolfgang Draxinger

mp2sleep@hotmail.com wrote:

> Just so that syntactic sugar is differentiated from feature
> availability, I want to know if a Toolkit designer would be
> able to provide a Windowing facility by just using OpenGL
> internally.

No.

> It is ok that OpenGL is "low-level", I presume line-drawing
> itself shall be enough to implement Windowing.

You're forgetting input handling, processing events from the
windowing system, etc. You can of course make a full screen
window and therein draw windows yourself (actually that is what
I'm doing in my engine's modeller) - but that is only 10% OpenGL
and the rest is implementing the whole windowing (user
interactin, input, events) stuff.

> What kind of performance hit or saving would one incur when
> compared to using the Win32 API?

Still you need the Win32 API (or DirectInput) to process the
actual input events. You can't circumvent this. But the window
your application is running in can only be created with the
functions of the windowing system (Win32, Xlib etc.)
(Theoretically you could circumvent the use of Xlib in a X11
environment, since this is a networked windowing system - so be
doing the whole communication yourself you could emulate Xlib;
however I don't see a reason, why someone would be so
masochistic to do this. However even such a DIY Xlib would still
have to implement the X protocol so you're still bound by the
used windowing system).

Also remember, that the Win32 windowing is done with high
priority in the operating system. Doing such stuff in the
application will be less performant in Win32 conditions (in X11
it doesn't matter, as it's done in userspace anyway). In my
modeller I'm doing it all myself, because it's _portable_ and
always looks the same, regardless of the used environment. And
as I'm using a own, uncommon UI scheme - with a very steep
learning curve (parts of the UI are inspired by blender, SGI's
Motif variant and a few other toolkits - I just took the best of
every concept and merged it) - this doesn't matter.

> I would be happy with any one of OpenGL or DirectX.

Rendering APIs are doing what the name suggests: They're
rendering. Well DirectX has some input stuff, but still you need
a window for your application and that can only be done with the
functions of your windowing system.

If your problem is portability: Use one of the wrapper libs.
GLUT, SDL mainly for pure rendering applications. Or a real
Toolkit wich OpenGL support: GTK, Qt, FLTK, wxWidgets. They're
all cross plattform and with a proper written code they can be
recompiled for every plattform without glitches.

--
Wolfgang Draxinger

> You're forgetting input handling, processing events from the
> windowing system, etc. You can of course make a full screen
> window and therein draw windows yourself (actually that is what
> I'm doing in my engine's modeller) - but that is only 10% OpenGL
> and the rest is implementing the whole windowing (user
> interactin, input, events) stuff.

Input, events are anyway not provided by OpenGL if I
am not mistaken.

User Interaction is about mapping I/O "events"
to coordinate positions on the Window, so I presume this
is as straight forward as I/O.
As you have mentioned, DirectX does seem to understand
input. The standard events such as maximize, minimize,
hitting the close button(or whatever it is called) are pretty
much universal if someone is looking for portability(I
am more interested in writing to as few different target
APIs on Windows as it is possible to do so).

> Still you need the Win32 API (or DirectInput) to process the
> actual input events. You can't circumvent this.

Agreed to the extent that OpenGL does not by itself
understand display-unrelated stuff, DirectX does.

> But the window
> your application is running in can only be created with the
> functions of the windowing system (Win32, Xlib etc.)

The Window that the Windowing system (Win32) would be relied
upon for creating can be an absolutely minimalistic Window
whose sole purpose is to establish a bounds for the
application which created that Window(resizing of Window
and all that goes through the native API).

>
> Also remember, that the Win32 windowing is done with high
> priority in the operating system. Doing such stuff in the
> application will be less performant in Win32 conditions (in X11
> it doesn't matter, as it's done in userspace anyway).

I/O performance is very difficult to measure. I presume
high-performance Game development is pretty much feasible
through OpenGL(QuakeIII is damn good), take away the universally
recognized events from the Toolkit and the remainder that
gets "routed" through OpenGL/DirectX wouldnt be in performance
terms, slower then Win32. What do you think?

> In my
> modeller I'm doing it all myself, because it's _portable_ and
> always looks the same, regardless of the used environment. And
> as I'm using a own, uncommon UI scheme - with a very steep
> learning curve (parts of the UI are inspired by blender, SGI's
> Motif variant and a few other toolkits - I just took the best of
> every concept and merged it) - this doesn't matter.

Is your modeller available as a free download :-) ?
Regards.