Multiple SDL Windows?

SDL Development
1

Hello!

I’m wondering if there are any plans to support
multiple windows with SDL? Is there any interest
in having such a feature in SDL?

SDL currently have fairly complete support for
window-manager interaction. If it also supported
creation of multiple windows at once, it would be
possible to create complete GUI applications
with it - including dialog-boxes, pop-up
menus and applications with several windows etc.

And I don’t even think it would change the
way that the SDL API works. It might be
necessary to add a flag to SDL_SetVideoMode
called something like SDL_EXTRAWINDOW, to
distinquish additional windows from the primary
window. I guess there should also be some
kind of support for closing the windows
again though… (SDL_FreeSurface?).

Cheers–
http://www.HardcoreProcessing.com

2

Hello!

I’m wondering if there are any plans to support
multiple windows with SDL?

It has been discussed, at least.

Is there any interest in having such a feature in SDL?

Yes.

SDL currently have fairly complete support for
window-manager interaction. If it also supported
creation of multiple windows at once, it would be
possible to create complete GUI applications
with it - including dialog-boxes, pop-up
menus and applications with several windows etc.

It would also be useful as a more generic solution for multihead support in
games.

And I don’t even think it would change the
way that the SDL API works. It might be
necessary to add a flag to SDL_SetVideoMode
called something like SDL_EXTRAWINDOW, to
distinquish additional windows from the primary
window. I guess there should also be some
kind of support for closing the windows
again though… (SDL_FreeSurface?).

The biggest problem is probably that the API and the design is assuming that
there is only one, global screen surface. An extra argument has to be added
to most of the calls, and there might still be global variables to move into
some private struct that belongs to the screen surface. (I think there is one
already…)

IIRC, “SDL 1.3” was the final word last time this was discussed.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 22 March 2001 23:55, Anoq of the Sun wrote:

3

David Olofson wrote:

I’m wondering if there are any plans to support
multiple windows with SDL?

The biggest problem is probably that the API and the design is assuming that
there is only one, global screen surface. An extra argument has to be added
to most of the calls, and there might still be global variables to move into
some private struct that belongs to the screen surface. (I think there is one
already…)

IIRC, “SDL 1.3” was the final word last time this was discussed.

Although this is problably a minority opinion, I really don’t like the
idea of SDL having support for multiple windows. This way it is simple,
small, and fast. If you want more windows, you should use the native
GUI to create more (I believe you can get a hold of the
platform-specific window object). If you want that to be
cross-platform, then put it in a seperate library with each platform’s
implementation. I don’t understand the motavation to use multiple
"DirectMedia" windows in a single program. It just seems like an
unnessecary complication with very little actual utility.

-- David Snopek

/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------

4

David Olofson wrote:

I’m wondering if there are any plans to support
multiple windows with SDL?

The biggest problem is probably that the API and the design is assuming
that there is only one, global screen surface. An extra argument has to
be added to most of the calls, and there might still be global variables
to move into some private struct that belongs to the screen surface. (I
think there is one already…)

IIRC, “SDL 1.3” was the final word last time this was discussed.

Although this is problably a minority opinion, I really don’t like the
idea of SDL having support for multiple windows. This way it is simple,
small, and fast.

I don’t see why an “extra” pointer indirection (that’s most probably always
there anyway, from what I’ve seen) would make a difference to performance…
The only calls I know of that would need an extra argument aren’t used more
than a few times per frame, at most, but I might be missing something.

If you don’t want to make it visible in the existing parts of the API, just
keep the current implicit global screen surface design, but add a call
"SDL_SelectWindow()" or similar. That way, old code will still compile and
work with the new API. (Although I’m not sure that’s an important design goal
of SDL 1.3…)

If you want more windows, you should use the native
GUI to create more (I believe you can get a hold of the
platform-specific window object).

The times I’ve thought “more than one SDL window would have been nice here”,
this would not have been of much help.

If you want that to be
cross-platform, then put it in a seperate library with each platform’s
implementation.

That would only make things worse. SDL is very portable - why would I throw
in a bunch of other APIs as well, if SDL does the job? (Well, short of the
multiple window support…)

I don’t understand the motavation to use multiple
"DirectMedia" windows in a single program. It just seems like an
unnessecary complication with very little actual utility.

To me, it’s not just about DirectMedia. It’s about using a nice, simple and
portable API, and still having the choice to go full screen, use direct video
APIs, OpenGL, not be restricted to a target with a windowing system etc,
while still having the choice of running like a “normal” application under X,
Win32 GUI, Mac OS or whatever - preferably without rewriting my low level
libs a few times!

SDL is very close, so “bypassing” it in various platform dependant ways,
rather than adding multiple window support, seems like a rather inefficient
and messy solution to me.

Finally; it could be argued that it’s good UI design to use the native GUI
for widgets, but it’s not really that simple.

Not all applications benefit from the beginner friendly native user
interfaces, but would work better with carefully tailored widgets. You have
to learn the application to use it efficiently anyway, so a beginner friendly
GUI would just be frustrating to experienced users. (I’m cursing over certain
applications that I use frequently for exactly that reason.)

In other applications (games, mostly) you just don’t want to use the native
widgets for interface design reasons - they don’t fit in, and hardly help
improving the game atmosphere. They may not even be compatible with the game
interface feel on some platforms.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 23 March 2001 02:40, David Snopek wrote:

5

To me, it’s not just about DirectMedia. It’s about using a nice, simple
and
portable API, and still having the choice to go full screen, use direct
video
APIs, OpenGL, not be restricted to a target with a windowing system etc,
while still having the choice of running like a “normal” application under
X,
Win32 GUI, Mac OS or whatever - preferably without rewriting my low level
libs a few times!

The idea of multiple windows is mutually exclusive with the idea of running
fullscreen. The only way to make them work together is if when you go
fullscreen you implement your own window manager and that’s going out of
scope of a library designed to port games.

I would recommend adding some 2D acceleration features to GUI libraries such
as wxWindows, instead. Besides, SDL is open-source so there’s nothing
stopping anybody from forking SDL and adding the features they want.–

Olivier A. Dagenais - Software Architect and Developer

6

The idea of multiple windows is mutually exclusive with the idea of running
fullscreen. The only way to make them work together is if when you go
fullscreen you implement your own window manager and that’s going out of
scope of a library designed to port games.

instead of SDL opening multiple windows, perhaps a better way would
be if SDL better allowed itself to be run in already created windows.

most gui toolkits offer some type of opengl widget. perhaps when
SDL is redesigned, it could be designed to easily allow the creation
of “SDL widgets”.

of course, there are still many sticky issues with that. first is
that not all gui toolkits are crossplatform. it would also have to
be clearly defined how SDL’s window manger-ish functions would behave
in certain environments. (although that is probably a good thing :] )

anyways, just a different perspective on things. technically it would
give you the same results. multiple SDL windows.

7

To me, it’s not just about DirectMedia. It’s about using a nice, simple
and
portable API, and still having the choice to go full screen, use direct
video
APIs, OpenGL, not be restricted to a target with a windowing system etc,
while still having the choice of running like a “normal” application
under X,
Win32 GUI, Mac OS or whatever - preferably without rewriting my low level
libs a few times!

The idea of multiple windows is mutually exclusive with the idea of running
fullscreen.

So, it’s motivated to interface your application with two different APIs to
switch between fullscreen and windowed mode, even if both modes are based on
the same higher level code, using the same graphics etc?

Some (well behaved) X and Windows applications support both panel/docking
based operation as well as windowed operation, and I don’t see why that
wouldn’t apply no games, game development tools and multimedia applications.

The only way to make them work together is if when you go
fullscreen you implement your own window manager and that’s going out of
scope of a library designed to port games.

Why should SDL implement the window manager? The required hooks are very
simple and low level, and together with the advanced clipping mentioned by
Mattias Engdeg?rd some times would even make it behave like a real windowing
system from the application POV.

The same API, as I picture it, would also be usable as a more structured
alternative to changing the screen clip rect all the time when rendering into
multiple views in games. The views would be almost totally independent, even
if they are on the same physical surface in a full screen mode - and they
could even overlap.

In short, it’s about using features that are generally useful and are
(probably, AFAIK) going in anyway, rather than adding new, totally unrelated
features, as seems to be the way the “multiwindow opposers” like to think of
it.

I would recommend adding some 2D acceleration features to GUI libraries
such as wxWindows, instead.

heh We’re not talking about trivial hacks there. Besides, it would not work
in fullscreen, not provide an SDL compatible API (without a great deal of
work at least), would not port to all platforms supported by SDL etc…

I’d actually prefer working on one of the existing SDL based toolkits, or
perhaps helping with the port of GTK+ (GDK, that is) to SDL. If that’s done
properly, we have a toolkit that’s more or less guaranteed to work wherever
SDL works, and that integrates nicely with SDL, whether we’re doing
fullscreen or multiwindow desktop based stuff.

Besides, SDL is open-source so there’s nothing
stopping anybody from forking SDL and adding the features they want.

Well, yeah, but forking is not a good idea for such a small feature. (Which
it is, unless something strange about SDL makes it virtually impossible to
manage more than one screen surface by design…)

I think the below API should pretty much cover what we’d need in the main SDL
tree to deal with all of this, including allowing third-party fullscreen mode
window managers to be plugged in at run time:On Friday 23 March 2001 05:16, Olivier Dagenais wrote:

SDL_Surface *SDL_CreateWindow(SDL_Surface *parent, SDL_Rect pos_size,
int bpp, Uint32 flags);
where “parent” is the parent surface, which may be any SDL surface
including the screen/root surface, which is referred to as surface
NULL. (The screen/root surface [NULL] is equivalent to the full
screen on fullscreen only targets, and when the SDL_FULLSCREEN flag
is set.) The “bpp” and “flags” arguments work similarly to those of
SDL_SetVideoMode().

SDL_MoveWindow(SDL_Surface *window, SDL_Rect pos_size);
Move and/or resize a window; be it a “real” window or a child window
of any SDL surface.

SDL_FreeWindow(SDL_Surface *window);

SDL_InstallWM(SDL_Surface *root, SDL_WMHook *wmhook);
where “root” is the surface that the installed WM is supposed to
manage child windows for, and “wmhook” is a structure containing
callback pointers (window creation hook, event hook, window
freeing hook,…) and other info.

SDL_RemoveWM(SDL_WMHook *wmhook);
Find and disconnect any instances of “wmhook” from the SDL core,
so that the WM code can safely be unloaded. (Well, this may not
make much sense unless there’s going to be a generic library/DLL
(un)loading system in 1.3+.)

(Well, I’ve probably missed a few details, but it’s not like this is supposed
to be a serious API proposal; I’ll at least hack a prototype on to of current
SDL before trying that. Not that I have time to do that… but I didn’t
really have time to play with the scrolling examples either. :wink:

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

8

Although this is problably a minority opinion, I really don’t like the
idea of SDL having support for multiple windows.

multiple windows aren’t really important but multiple screens are.
The former is a logical consequence of the latter and useful for debugging
and as a pure side-effect those who want it for windowed applications
get it as well

9

The idea of multiple windows is mutually exclusive with the idea of
running fullscreen. The only way to make them work together is if when
you go fullscreen you implement your own window manager and that’s going
out of scope of a library designed to port games.

instead of SDL opening multiple windows, perhaps a better way would
be if SDL better allowed itself to be run in already created windows.
most gui toolkits offer some type of opengl widget. perhaps when
SDL is redesigned, it could be designed to easily allow the creation
of “SDL widgets”.

Nice idea, although it addresses a slightly different set of problems from
what I’m thinking about, and it’s not totally inclusive. It would fit in
rather nicely, though, at least from the API POV, I think.

Anyway, I don’t see how it could be significantly less complicated than
actually supporting multiple windows “properly” in the API as well.

Also note “connecting” SDL to any form of platform dependent windows is
inherently non-portable. Just for starters, you’ll get at least one argument
that has different types on different targets.

of course, there are still many sticky issues with that. first is
that not all gui toolkits are crossplatform. it would also have to
be clearly defined how SDL’s window manger-ish functions would behave
in certain environments. (although that is probably a good thing :] )

Well, if it’s supposed to work properly with the WM calls as well, it might
as well be done properly… We’re not talking about just adding a flag to
SDL_SetVideoMode() anyway.

anyways, just a different perspective on things. technically it would
give you the same results. multiple SDL windows.

Yeah, but in a way that’s totally non-portable, in some cases even when done
on top of portable toolkits! (Well, unless SDL is supposed to explicitly
support those toolkits, just to be able to get the window handles out of
their widgets…) And it still wouldn’t work in fullscreen modes, or for
child windows on SDL surfaces.

Why mess with that if you don’t really want to run SDL in an existing
window?

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 23 March 2001 05:40, Pete Shinners wrote:

10

David Snopek wrote:

IIRC, “SDL 1.3” was the final word last time this was discussed.

Although this is problably a minority opinion, I really don’t like the
idea of SDL having support for multiple windows. This way it is simple,
small, and fast. If you want more windows, you should use the native
GUI to create more (I believe you can get a hold of the
platform-specific window object). If you want that to be
cross-platform, then put it in a seperate library with each platform’s
implementation.

Really huge work.

I don’t understand the motavation to use multiple
"DirectMedia" windows in a single program. It just seems like an
unnessecary complication with very little actual utility.

There is such motivation.
There are peoples who want to use SDL not only for games development.
SDL looks as a very good base for general cross-platform development.

Best wishes,
Alexei Nikitin.

11

David Olofson wrote:

The biggest problem is probably that the API and the design is assuming that
there is only one, global screen surface. An extra argument has to be added
to most of the calls, and there might still be global variables to move into
some private struct that belongs to the screen surface. (I think there is one
already…)

Actually, I think that most calls take an SDL_Surface explicitly -
and SDL_SetVideoMode returns an SDL_Surface too - so I’m not
sure it will need many API changes :slight_smile:

IIRC, “SDL 1.3” was the final word last time this was discussed.

OK - thanks…

Cheers–
http://www.HardcoreProcessing.com

12

That’s exacly what I mean when I’m saying that this is about making use of
functionality that we want anyway.

BTW, debugging multihead programs on a single monitor using windowed mode is
a very interesting idea - didn’t really think of that variant! :slight_smile:

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 23 March 2001 10:24, Mattias Engdeg?rd wrote:

Although this is problably a minority opinion, I really don’t like the
idea of SDL having support for multiple windows.

multiple windows aren’t really important but multiple screens are.
The former is a logical consequence of the latter and useful for debugging
and as a pure side-effect those who want it for windowed applications
get it as well

13

Indeed it is, and I’m planning to base a GUI toolkit for MAIA plugins on it,
just so I can get the benefits of fast and accurate rendering (very important
for the glossy GUIs that Cubase VST users are used to…) as well as
portability.

The only showstopper is that I have to run every GUI in a separate process
with current SDL. Not very handy or efficient, as GUI plugins (just like
processing plugins) are callback driven, rather than running as stand-alone
processes. The proper way is to run all of them in a single process; the “GUI
Plugin Host”, which means that lots of small plugin GUIs can easily be
displayed right inside the track/arrange view of audio sequencers and similar
things.

Implementing that kind of stuff for X alone is a big job, and then porting it
to fbdev for dedicated audio workstations, synths, samplers, HDRs, Win32 for
users that don’t need ultra low latency audio, Mac OS etc… No thanks. SDL
with multi window support would be just perfect, as I have to design a
custom toolkit anyway. (“Normal” toolkits aren’t fast, flexible or glossy
enough.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 23 March 2001 11:29, Alexei Nikitin wrote:

David Snopek wrote:

IIRC, “SDL 1.3” was the final word last time this was discussed.

Although this is problably a minority opinion, I really don’t like the
idea of SDL having support for multiple windows. This way it is simple,
small, and fast. If you want more windows, you should use the native
GUI to create more (I believe you can get a hold of the
platform-specific window object). If you want that to be
cross-platform, then put it in a seperate library with each platform’s
implementation.

Really huge work.

I don’t understand the motavation to use multiple
"DirectMedia" windows in a single program. It just seems like an
unnessecary complication with very little actual utility.

There is such motivation.
There are peoples who want to use SDL not only for games development.
SDL looks as a very good base for general cross-platform development.

14

Well, I realized that after some more thought. There are some calls that
expect a global screen surface, but it’s probably only an improvement in
consistency to “fix” them.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 23 March 2001 12:36, Anoq of the Sun wrote:

David Olofson wrote:

The biggest problem is probably that the API and the design is assuming
that there is only one, global screen surface. An extra argument has to
be added to most of the calls, and there might still be global variables
to move into some private struct that belongs to the screen surface. (I
think there is one already…)

Actually, I think that most calls take an SDL_Surface explicitly -
and SDL_SetVideoMode returns an SDL_Surface too - so I’m not
sure it will need many API changes :slight_smile:

15

Olivier Dagenais wrote:

The idea of multiple windows is mutually exclusive with the idea of running
fullscreen. The only way to make them work together is if when you go
fullscreen you implement your own window manager and that’s going out of
scope of a library designed to port games.

This idea seems nice at first - but I’ll agree with David Olofson that
you get a non-portable function-argument to your functions.

And actually, I think it’s perfectly OK if fullscreen and
several windows are mutually exclusive features. If you’re
running full screen, you can just manage your own arbitrary
rectangles on the screen and call them “windows” - this
is already perfectly do-able with SDL as it is now.
But creating a desktop application with seveal SDL windows
is not possible. If we’re talking multi-head support, then
several full-screen surfaces also starts to make sense - and
they would still be completely indepedent screens.

David Olofson wrote:

SDL_Surface *SDL_CreateWindow(SDL_Surface *parent, SDL_Rect pos_size,
int bpp, Uint32 flags);
where “parent” is the parent surface, which may be any SDL surface
including the screen/root surface, …
SDL_MoveWindow(SDL_Surface *window, SDL_Rect pos_size);
SDL_FreeWindow(SDL_Surface *window);
SDL_InstallWM(SDL_Surface *root, SDL_WMHook *wmhook);
SDL_RemoveWM(SDL_WMHook *wmhook);

I certainly wouldn’t mind being able to create windows
layered on top of each other - but I can see if somebody
thinks that this is starting to get out of the scope of SDL.
I think separate “top-level” windows would be adequate -
and I really think it can be done with an extra flag to
SDL_SetVideoMode or something. Of course - it should
be possible to close, move, resize the window and
interact with the window manager etc.

It would even be possible to create something like your
SDL_CreateWindow function on top of SDL_SetVideoMode! :slight_smile:
…If only SDL had support for several “top-level” windows
that is. The CreateWindow function could mangage it’s
own sub-windows.

Alexei Nikitin wrote:

David Snopek wrote:

I don’t understand the motavation to use multiple
"DirectMedia" windows in a single program. It just seems like an
unnessecary complication with very little actual utility.

There is such motivation.
There are peoples who want to use SDL not only for games development.
SDL looks as a very good base for general cross-platform development.

Yes - what I want to use it for is to create a cross-platform
GUI toolkit on top of SDL - and I want it to be possible to
create look & feels out of bitmap graphics and to run the
applications like “normal” desktop applications with pop-up
menus, several windows etc.

Actually I’m talking about an SDL backend for my GUI toolkit in ML:
http://www.HardcoreProcessing.com/pro/abstractuiml/index.html

(it’s very outdated, so it really does need a decent backend :wink:

Cheers–
http://www.HardcoreProcessing.com

16

Olivier Dagenais wrote:

The idea of multiple windows is mutually exclusive with the idea of
running fullscreen. The only way to make them work together is if when
you go fullscreen you implement your own window manager and that’s going
out of scope of a library designed to port games.

This idea seems nice at first - but I’ll agree with David Olofson that
you get a non-portable function-argument to your functions.

And actually, I think it’s perfectly OK if fullscreen and
several windows are mutually exclusive features. If you’re
running full screen, you can just manage your own arbitrary
rectangles on the screen and call them “windows” - this
is already perfectly do-able with SDL as it is now.

Uhm, kind of, but not really like a real windowing system; current SDL
clipping doesn’t handle overlapping “windows”, and even if it did have
complex clipping (multiple rects at least), you’d still have to do some extra
work to get it right - whereas that would be done once and for all, and
possibly in a carefully optimized way, in SDL if there was (child) windowing
support.

But creating a desktop application with seveal SDL windows
is not possible.

Right.

If we’re talking multi-head support, then
several full-screen surfaces also starts to make sense - and
they would still be completely indepedent screens.

Yep.

David Olofson wrote:

SDL_Surface *SDL_CreateWindow(SDL_Surface *parent, SDL_Rect pos_size,
int bpp, Uint32 flags);
where “parent” is the parent surface, which may be any SDL
surface including the screen/root surface, …
SDL_MoveWindow(SDL_Surface *window, SDL_Rect pos_size);
SDL_FreeWindow(SDL_Surface *window);
SDL_InstallWM(SDL_Surface *root, SDL_WMHook *wmhook);
SDL_RemoveWM(SDL_WMHook *wmhook);

I certainly wouldn’t mind being able to create windows
layered on top of each other - but I can see if somebody
thinks that this is starting to get out of the scope of SDL.

Why? If one of the criteria is that it should be hardware accelerated; well,
there are cards that can accelerate overlapping windows in various ways.

Either way, integrating that kind of clipping with the “normal” clipping
still makes a lot of sense. If you’ve got multiple rectangle clip regions,
it’s just a matter of setting a region up for each window, and make sure the
right region is used when rendering into each window.

I think separate “top-level” windows would be adequate -
and I really think it can be done with an extra flag to
SDL_SetVideoMode or something. Of course - it should
be possible to close, move, resize the window and
interact with the window manager etc.

Some calls would need an extra argument, but yes, it would most probably
work… However, it seems to me that it’s further away from the main SDL
design goals if it’s only supported on windowed targets, and doesn’t work
at all in fullscreen modes.

It would even be possible to create something like your
SDL_CreateWindow function on top of SDL_SetVideoMode! :slight_smile:

Well, SDL_CreateWindow() (or something with a more suitable name) was
actually meant to replace SDL_SetVideoMode() with something more flexible.

…If only SDL had support for several “top-level” windows
that is. The CreateWindow function could mangage it’s
own sub-windows.

Well, that’s kind of what I had in mind from the beginning - only it seems
cleaner to let SDL handle the clipping as well. Unless complex clip regions
aren’t going to happen, that is.

Alexei Nikitin wrote:

David Snopek wrote:

I don’t understand the motavation to use multiple
"DirectMedia" windows in a single program. It just seems like an
unnessecary complication with very little actual utility.

There is such motivation.
There are peoples who want to use SDL not only for games development.
SDL looks as a very good base for general cross-platform development.

Yes - what I want to use it for is to create a cross-platform
GUI toolkit on top of SDL - and I want it to be possible to
create look & feels out of bitmap graphics and to run the
applications like “normal” desktop applications with pop-up
menus, several windows etc.

We’re thinking about the same things it seems. :slight_smile:

However, I don’t consider rendering into a “real” surface (screen or "real"
window) very different from rendering into a sub surface, which is actually
just a reference to a part of a “real” surface. I just don’t see why clipping
info, window z order etc should be ripped out of SDL for processing by an
add-on library and then fed back into SDL. I also don’t see why you should
need an additional layer of abstraction separating windows from surfaces on
the rendering level - which would be required if this was to be done in a
separate lib. It just seems messy…

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 23 March 2001 13:38, Anoq of the Sun wrote:

17

Actually, you can already do multiple windows using SDL, tho I’m not sure how
portable the technique is (I must admit I am totally ignorant of non-POSIX
environments :wink:

You could use any number of IPC methods to get multiple processes with multiple
windows.

I would even assume (tho I have not tried it myself, so if I am wrong, please
correct me) that you could fork a process (before you create a screen) and do
it that way as well.On Thu, 22 Mar 2001, you wrote:

Hello!

I’m wondering if there are any plans to support
multiple windows with SDL? Is there any interest
in having such a feature in SDL?

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

18

Samuel Hart wrote:

You could use any number of IPC methods to get multiple processes with multiple
windows.

I would even assume (tho I have not tried it myself, so if I am wrong, please
correct me) that you could fork a process (before you create a screen) and do
it that way as well.

OK - that might be do-able, but I think it would be a pretty
messy way of doing it - especially from ML with a
compiler generating C-code which is most likely not
thread-safe :wink:

David Olofson wrote:

Either way, integrating that kind of clipping with the “normal” clipping
still makes a lot of sense. If you’ve got multiple rectangle clip regions,
it’s just a matter of setting a region up for each window, and make sure the
right region is used when rendering into each window.

OK - hardware accelerated clipping makes sense :slight_smile:
But I’m writing my own clipping routines for that
anyway… - but I sure wouldn’t mind the general clipping
being there :slight_smile:

However, it seems to me that it’s further away from the main SDL
design goals if it’s only supported on windowed targets, and doesn’t work
at all in fullscreen modes.

Well, I was just thinking:
several full-screen windows = several monitors,
and not “windows” inside the full-screen window.

But anyways - as long as there’s some way of
having multiple windows, I’m sure that whatever
solution comes up would work for what I want :slight_smile:

But I guess some design will have to be agreed upon
if anyone is to start implementing anything :slight_smile:

Cheers–
http://www.HardcoreProcessing.com

19

FWIW, I agree. You’d probably also need an SDL_CloseVideoWindow (or similar)
function to shut down individual displays (the normal way is
SDL_QuitSubSystem(SDL_INIT_VIDEO), which is fine for single windows). The
QuitSubSystem method would of course continue to work for single instances –
I think this could be done without harming backward compatibility at all.

Multiple windows don’t make sense for fullscreen applications, but there are
plenty of cases where it would be extremely useful to open multiple video
windows from a single process without losing SDL’s power.

-JohnOn Saturday 24 March 2001 19:18, you wrote:

Anoq of the Sun wrote:

David Olofson wrote:

However, it seems to me that it’s further away from the main SDL
design goals if it’s only supported on windowed targets, and doesn’t
work at all in fullscreen modes.

Well, I was just thinking:
several full-screen windows = several monitors,
and not “windows” inside the full-screen window.

For what the opinion of a complete newbie is worth – I
like the multi-screen = multi-monitor or multiple
windows on an existing window manager. Trying to
make SDL itself manage windows sounds like a bad
thing (though one could imagine an external library
to do it).

This is in fact how I guessed that SDL would work,
based on the abstraction of using a surface to represent
the screen. Very few routines seem to assume that
there’s only one screen (I can only think of
SDL_DisplaySurface() off-hand – but then, as I said,
I’m a newbie). It seems a very natural extension to
simply call SDL_SetVideoMode() twice and get two
windows if it’s running under a window manager. On
a single-head system, the second one ought to simply
replace the first. On systems like Linux/X where
there can be more than one monitor or terminal, the
idea of specifying which monitor you mean also seems
natural. The window manager worries about the placement
of the windows and whether they can be moved, closed,
etc, while for separate monitors, the geometry is
hardwired (i.e. the screens have a fixed size).

–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software

20

Anoq of the Sun wrote:

David Olofson wrote:

However, it seems to me that it’s further away from the main SDL
design goals if it’s only supported on windowed targets, and doesn’t work
at all in fullscreen modes.

Well, I was just thinking:
several full-screen windows = several monitors,
and not “windows” inside the full-screen window.

For what the opinion of a complete newbie is worth – I
like the multi-screen = multi-monitor or multiple
windows on an existing window manager. Trying to
make SDL itself manage windows sounds like a bad
thing (though one could imagine an external library
to do it).

This is in fact how I guessed that SDL would work,
based on the abstraction of using a surface to represent
the screen. Very few routines seem to assume that
there’s only one screen (I can only think of
SDL_DisplaySurface() off-hand – but then, as I said,
I’m a newbie). It seems a very natural extension to
simply call SDL_SetVideoMode() twice and get two
windows if it’s running under a window manager. On
a single-head system, the second one ought to simply
replace the first. On systems like Linux/X where
there can be more than one monitor or terminal, the
idea of specifying which monitor you mean also seems
natural. The window manager worries about the placement
of the windows and whether they can be moved, closed,
etc, while for separate monitors, the geometry is
hardwired (i.e. the screens have a fixed size).

I wrote my debugging code assuming that this was the
way SDL would work (though I didn’t try it – I just
used the same window for everything). Had my code
required more complicated debugging images, it would’ve
been real nice to be able to show that in a separate
window.

Just my opinion. Got lots of them, for those who
care to listen. ;)–
Terry Hancock
@Terry_Hancock