Multiple SDL Windows?

Sam_Hart · March 25, 2001, 5:02pm

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

Actually, not necessarily true.

I’m hacking together an example, and will try to post it a little later on for
anyone interested.

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

Actually, I just realized, if all anyone wants (and I know you don’t is
“windows” inside the full-screen window, this could be handled easily enough
(perhaps not very efficiently) by just using multiple surfaces inside the
window that act as windows themselves (i.e., you blit things to them, and then
blit them to the full screen window… kinda slow and clunky, but doable).On Sat, 24 Mar 2001, you wrote:

–
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/ >

Sam_Hart · March 25, 2001, 7:01pm

Here’s my quick example for making a multi-windowed SDL app using fork() and
pipe(). It can be found on my demo/example code page (presently, the only thing
there):

http://www.geekcomix.com/snh/files/demos/

A direct link to the file is

http://www.geekcomix.com/snh/files/demos/multiwin.tar.gz

I doubt this is very portable to non-POSIX systems, but I really have no way of
verifying that assumption.–
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/ >

David_Olofson · March 25, 2001, 7:12pm

My idea is to make these windows “false” surfaces, that only
reference the real screen surface.

However, that requires rectangle list based clipping, which is not
yet available. It also requires a notion of write only surfaces, as
you’d not get what you expect when reading back from a sub
surface/child window, due to overlapping.

How about a flag SDL_WRITEONLY to the new SDL_CreateWindow()
function? That would allow sub surfaces to be implemented the “right”
way, with clipping instead of extra copying, while the API would
still be consistent (which seems like a good idea), and use the
method you described if this flag is not set.

//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 Sunday 25 March 2001 19:02, Samuel Hart wrote:

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

Actually, I just realized, if all anyone wants (and I know you
don’t is “windows” inside the full-screen window, this could be
handled easily enough (perhaps not very efficiently) by just using
multiple surfaces inside the window that act as windows themselves
(i.e., you blit things to them, and then blit them to the full
screen window… kinda slow and clunky, but doable).

David_Olofson · March 25, 2001, 5:44pm

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

That shouldn’t be an issue, as you rely on entirely separate
processes + IPC, rather than threading. That is, the processes will
be using separate instances of SDL and all other libraries, so
nothing needs to be thread safe.

[…]

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.

Exactly. That seems to be the most important reason why multiple
screen surface support in SDL is desired. The other things we’re
discussing here are just logical bonus effects of the API required to
do that.

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

Well, the separate process method would work for me as well, although
I’d have to implement the child-window-on-SDL-surface thing myself,
clipping included, meaning that I’d have to use a different API when
rendering in a child window. No big deal, but I think it’s quite
wasteful if people have to reinvent the wheel over and over again to
do this kind of stuff, when it would fit nicely into the new SDL API.

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

Of course. And that’s the problem; if it’s done as an external
library, you have to chose between the wrapper API of that library,
or the SDL API. Also, it always seems that such libraries tend to
grow too big and complex to be kept generic, with the net result that
few use them.

Just as an example, how many SDL toolkits do we have? How many
projects are using them, rather than their own, custom solutions…?
(Note: This is not to say that SDL should have a native toolkit; it’s
just an example of the problem with libraries that address too many
problems at once.)

//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 Saturday 24 March 2001 19:24, Anoq of the Sun wrote:

David_Olofson · March 25, 2001, 7:01pm

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).

Exactly. Add a generic library/DLL loading API, and users can pick
their favourite SDL WM - or hack their own - for any SDL application
or game that uses child windows.

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.

Hmm… I think it should either open on a separate console (Linux),
or simply fail. The old surface mysteriously “disappearing” sounds
weird to me.

//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 Sunday 25 March 2001 01:18, Terry Hancock wrote:

David_Olofson · March 25, 2001, 6:56pm

[…]

Multiple windows don’t make sense for fullscreen applications, but

Why? Does it make more sense to move the cliprect around when
managing a game screen with multiple display areas?

Also, in seems rather logical to me to provide the (rather simple)
hooks required to snap in a window manager, so that SDL applications
that were designed for targets with a windowing system can be ported
to fullscreen-only targets.

I’d rather not to put X and a standard WM on an embedded system, for
example, but a windowed GUI with high performance can still
beessential, as that’s what many users expect. Just for starters, the
standard key bindings of X WMs work well for normal desktops, but are
pretty useless when you want full control of a single, specialized
application. An SDL fullscreen mode with window based clipping and a
simple hook for a custom WM would be perfect in that scenario.

//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 Sunday 25 March 2001 00:24, John R. Hall wrote:

ANOQ_of_the_Sun · March 25, 2001, 9:18pm

David Olofson wrote:

Well, the separate process method would work for me as well, although
I’d have to implement the child-window-on-SDL-surface thing myself,
clipping included, meaning that I’d have to use a different API when
rendering in a child window. No big deal, but I think it’s quite
wasteful if people have to reinvent the wheel over and over again to
do this kind of stuff, when it would fit nicely into the new SDL API.

Just came to think of it - I think it would currently
be possible to allocate an SDL_Surface structure
and initialize it with proper width, height, pitch,
pixels pointer, cliprects etc. so that it really
works as a sub-rectangle on a bigger SDL_Surface -
even with correct coordinate system etc.

The “only” thing which would not (currently) be
possible is writing to a rectangle with other
rectangles overlapping it.

That’s what would be possible with your
approach… I don’t know - maybe you’re
right that this should be supported natively.
And it’s still a simple kind of abstraction -
which both X and Win32 (and possibly also most
other Windoing systems) uses natively too…

Cheers–
http://www.HardcoreProcessing.com

David_Olofson · March 26, 2001, 4:30am

David Olofson wrote:

Well, the separate process method would work for me as well,
although I’d have to implement the child-window-on-SDL-surface
thing myself, clipping included, meaning that I’d have to use a
different API when rendering in a child window. No big deal, but
I think it’s quite wasteful if people have to reinvent the wheel
over and over again to do this kind of stuff, when it would fit
nicely into the new SDL API.

Just came to think of it - I think it would currently
be possible to allocate an SDL_Surface structure
and initialize it with proper width, height, pitch,
pixels pointer, cliprects etc. so that it really
works as a sub-rectangle on a bigger SDL_Surface -
even with correct coordinate system etc.

Yeah, that’s exactly how I intend it to be done, at least in the case
when you don’t require the surface to be readable in aconsistent way.
(See previous post with API “proposal”.)

The “only” thing which would not (currently) be
possible is writing to a rectangle with other
rectangles overlapping it.

That’s what would be possible with your
approach… I don’t know - maybe you’re
right that this should be supported natively.
And it’s still a simple kind of abstraction -
which both X and Win32 (and possibly also most
other Windoing systems) uses natively too…

Right; and if complex clipping is going in anyway, there shouldn’t be
much glue needed between that and the sub surfaces to turn the latter
into real windows.

(Note: We’re not talking about windows with decorations and crap;
just plain rectangular drawing areas, like raw X windows or Win32
drawing contexts.)

//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 Sunday 25 March 2001 23:18, Anoq of the Sun wrote: