Hi all!
What about adding a SDL_MULTIPLEWINDOWS flag to SDL_Init() which enables
the necessary API changes?
There must be a major disadvantage, or it would have been done long ago.
See you, Jakob–
Im Ausblick auf den bevorstehenden Winter habe ich mir eine
hochwertige Elektroheizung zugelegt (Thunderbird 1,4 GHZ)."
Sven Arnhold in tuc.comp
Argh, konsole + curses = mess (on my gcc2.96 system)
The subject is supposed to be "Multiple windows proposal(??)"On Mon, Mar 04, 2002 at 09:32:28PM +0100, Jakob Kosowski wrote:
–
Im Ausblick auf den bevorstehenden Winter habe ich mir eine
hochwertige Elektroheizung zugelegt (Thunderbird 1,4 GHZ)."
Sven Arnhold in tuc.comp
The API isn’t a problem - in fact, you only have to extend it with two or
three calls.
The problem is the rendering backend implementations, and the internal
structures they rely on. Currently, the design is based on the idea that
you have a “output context”, and then SDL is based upon that. A rendering
backend interfaces the common parts of SDL with the underlying target,
and the only “adressing info” passed to it is that of the “screen
context”.
Unfortunately, there are a few targets that require that you separate
that “output context” into a global “screen context”, and then one
"window context" for each window. On those targets, it’s not possible to
have multiple “screen contexts” in the same process, so there’s no simple
and portable workaround. A substantial reorganization of SDL’s internals
is required.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 04 March 2002 21:32, Jakob Kosowski wrote:
Hi all!
What about adding a SDL_MULTIPLEWINDOWS flag to SDL_Init() which
enables the necessary API changes?There must be a major disadvantage, or it would have been done long
ago.
What about adding a SDL_MULTIPLEWINDOWS flag to SDL_Init() which enables
the necessary API changes?There must be a major disadvantage, or it would have been done long ago.
Not all targets (fbcon, OpenGL on a Voodoo2, etc) can support multiple
windows. It is also easier to implement and use the API when there is only
one window to work on (so you aren’t switching “contexts” or anything like
that).
That being said, SDL 1.3 has a proposed way of managing multiple windows,
but is not slated for release for 18 jazillian years. 
Generally speaking, at this point in time, most programs that need
multiple windows either only THINK they need them, but are better served
by a different design, or only THINK they need to use SDL, but are better
served by a different library (like GTK+).
ymmv.
–ryan.
I always feel like a complete dork when I get answers from this list.
See you, JakobOn Mon, Mar 04, 2002 at 10:17:35PM +0100, David Olofson wrote:
Unfortunately, there are a few targets that require that you separate
that “output context” into a global “screen context”, and then one
"window context" for each window. On those targets, it’s not possible to
have multiple “screen contexts” in the same process, so there’s no simple
and portable workaround. A substantial reorganization of SDL’s internals
is required.
–
Im Ausblick auf den bevorstehenden Winter habe ich mir eine
hochwertige Elektroheizung zugelegt (Thunderbird 1,4 GHZ)."
Sven Arnhold in tuc.comp
Actually, I wouldn’t mind a hack that just allows multiple windows to each
be considered a “screen”. I think The only part that would require moderate
SDL changes is event handling.
-RayOn Mon, Mar 04, 2002 at 10:17:35PM +0100, David Olofson wrote:
On Monday 04 March 2002 21:32, Jakob Kosowski wrote:
Hi all!
What about adding a SDL_MULTIPLEWINDOWS flag to SDL_Init() which
enables the necessary API changes?There must be a major disadvantage, or it would have been done long
ago.The API isn’t a problem - in fact, you only have to extend it with two or
three calls.The problem is the rendering backend implementations, and the internal
structures they rely on. Currently, the design is based on the idea that
you have a “output context”, and then SDL is based upon that. A rendering
backend interfaces the common parts of SDL with the underlying target,
and the only “adressing info” passed to it is that of the “screen
context”.Unfortunately, there are a few targets that require that you separate
that “output context” into a global “screen context”, and then one
"window context" for each window. On those targets, it’s not possible to
have multiple “screen contexts” in the same process, so there’s no simple
and portable workaround. A substantial reorganization of SDL’s internals
is required.
Actually, I wouldn’t mind a hack that just allows multiple windows to each
be considered a “screen”. I think The only part that would require moderate
SDL changes is event handling.
…and a complete rewrite of the behind-the-scenes code.
API proposals are easy. Code rewrites aren’t.
–ryan.
Well, that’s exactly what I had in mind when I first suggested a hack
like this. And in fact, I’m not sure it would be much of a hack at all,
at least not as long as we accept the fact that SDL would still not be
thread safe. (A state machine style API with explicit "context switches"
is just fine, as long as you stick to a single thread.)
The problem is that in the above, I’m not talking about the API, but
about the internals. On some targets, it’s simply not possible to open
the “backend” twice - you have to open the “backend” once, and then
open one “window” for each SDL “screen”. This is where the current design
of SDL’s internals causes major problems - SDL doesn’t distinguish
between “backend” and “window”.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 05 March 2002 01:08, Ray Kelm wrote:
On Mon, Mar 04, 2002 at 10:17:35PM +0100, David Olofson wrote:
On Monday 04 March 2002 21:32, Jakob Kosowski wrote:
Hi all!
What about adding a SDL_MULTIPLEWINDOWS flag to SDL_Init() which
enables the necessary API changes?There must be a major disadvantage, or it would have been done long
ago.The API isn’t a problem - in fact, you only have to extend it with
two or three calls.The problem is the rendering backend implementations, and the
internal structures they rely on. Currently, the design is based on
the idea that you have a “output context”, and then SDL is based upon
that. A rendering backend interfaces the common parts of SDL with the
underlying target, and the only “adressing info” passed to it is that
of the “screen context”.Unfortunately, there are a few targets that require that you separate
that “output context” into a global “screen context”, and then one
"window context" for each window. On those targets, it’s not possible
to have multiple “screen contexts” in the same process, so there’s no
simple and portable workaround. A substantial reorganization of SDL’s
internals is required.Actually, I wouldn’t mind a hack that just allows multiple windows to
each be considered a “screen”. I think The only part that would require
moderate SDL changes is event handling.
Ray Kelm wrote:
Actually, I wouldn’t mind a hack that just allows multiple windows to each
be considered a “screen”. I think The only part that would require moderate
SDL changes is event handling.
From the SDL programmers point of view it would be nice to treat each
window as an sdl surface and to add the sdl surface structure address to
the event structure to distinguish events originating on differenct
surfaces. Then inside each SDL api you would have to add code to vector
the requested operation to the correct implementation based on surface
flags or something similar.
SDL is already structured pretty much that way. It would add some code
and probably slow down everything a little bit. Is is worth it?
Bob Pendleton> On Mon, Mar 04, 2002 at 10:17:35PM +0100, David Olofson wrote:
-Ray
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+
Ray Kelm wrote:
(No, I didn’t - Ray Kelm did. Anyway…)
Actually, I wouldn’t mind a hack that just allows multiple windows to
each be considered a “screen”. I think The only part that would
require moderate SDL changes is event handling.From the SDL programmers point of view it would be nice to treat each
window as an sdl surface
…just like the current “screen” is handled…
and to add the sdl surface structure address
to the event structure to distinguish events originating on differenct
surfaces.
Yes, something like that would be required. It could even be done without
breaking binary compatibility with old applications. (You can’t just
extend the “real” event struct, because that would make old applications
crash when the read events.)
Then inside each SDL api you would have to add code to vector
the requested operation to the correct implementation based on surface
flags or something similar.
If we assume that all windows will have the same pixel format and run on
the same target, that wouldn’t really be necessary.
If we assume that SDL isn’t redesigned to be thread safe, and use
explicit context switching calls, nothing like that would be needed at
all, as you’ll always be operating on the currently selected context.
Just swap some of SDL’s internal variables when switching context, and
that’s it.
SDL is already structured pretty much that way. It would add some code
and probably slow down everything a little bit. Is is worth it?
I don’t think there would by any slowdown at all, except some in the
event system, as no changes to the actual blitting code would be
required. Instead, you take the full “impact” when doing an explicit
context switch - which means that there’s no cost unless you use multiple
"screens".
Either way, there are still a bunch of targets that need a redesign of
SDL’s internals for this to be possible. I don’t know exactly how much
work it would be, but I’ve been told that it’s rather sustantial. Seems
like it’s not wortwhile to do something like that before 1.3.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 06 March 2002 21:25, Bob Pendleton wrote:
On Mon, Mar 04, 2002 at 10:17:35PM +0100, David Olofson wrote:
Then inside each SDL api you would have to add code to vector
the requested operation to the correct implementation based on surface
flags or something similar.
If we assume that all windows will have the same pixel format and run on
the same target, that wouldn’t really be necessary.
What about things like twinview ? If SDL is going to support multiple
screens, one of those screens might be on another monitor, with different
settings, etc … Which brings another question to mind; what happens if a SDL
window is moved from one screen to another today ?
Btw, would be nice to have multi-monitor support in SDL … 3D games could use
it for multiple viewpoints, 2D games for different screens … etc
SDL @ xinerama! =)–
Trick
“There is no magic” - Nakor, magic user
Btw, would be nice to have multi-monitor support in SDL … 3D games could use
it for multiple viewpoints, 2D games for different screens … etc
This is the reason for the planned multi-window support in 1.3. The fact
that you can have separate windows is actually just a side effect of this
support.
–ryan.