For various reasons, I’m interested in using multiple
SDL video (software) surfaces as part of
desktop applications that have multiple top-level
windows. Although I’m new to SDL, my
initial inspection of the code indicates that this
is not supported since the omnipresent THIS/this
variable in the implementation is global.
Is that correct? If not, could someone point me
to an example of this type of usage? If so,
would there be any significant downside to a
modification of the SDL library to allow for
multiple video surfaces, with an application level
API to designate which one is ‘current’? What,
if any, are the hidden gotchas there? I realize that
the event handling would need to be slightly modified.
as far as i know this is completly impossible (at last with a single
process)
you should either wait for SDL 1.3 (roughly 1 year, and it is planned)
or write a multiprocess pipe with a kind of multi process communication:
- shared memory
- pipe
- socket
For various reasons, I’m interested in using multiple
SDL video (software) surfaces as part of
desktop applications that have multiple top-level
windows. Although I’m new to SDL, my
initial inspection of the code indicates that this
is not supported since the omnipresent THIS/this
variable in the implementation is global.
Is that correct?
Yes.
If not, could someone point me
to an example of this type of usage? If so,
would there be any significant downside to a
modification of the SDL library to allow for
multiple video surfaces, with an application level
API to designate which one is ‘current’?
This has been discussed, and indeed, there are various more or less nice
and simple ways of selecting ‘current’ surface, but…
What,
if any, are the hidden gotchas there? I realize that
the event handling would need to be slightly modified.
that’s probably the major gotcha. This is hard to do without breaking
compatibility, and it’s quite some work to do it in a useful way.
For now, fork off a new process for each window, and use some form of IPC
to communicate between them.
//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 09 October 2001 22:05, Josh Stern wrote:
At 23:13 Uhr +0200 09.10.2001, David Olofson wrote:
[…]
What,
if any, are the hidden gotchas there? I realize that
the event handling would need to be slightly modified.that’s probably the major gotcha. This is hard to do without breaking
compatibility, and it’s quite some work to do it in a useful way.
Another “gotcha” is that it is not possible to do this at all on some
of SDLs backends, e.g. fbcon. Of course in future SDL versions, this
shoudl just be an attribut of the backend that tells whether it is
capable of doing this or not.
Max>On Tuesday 09 October 2001 22:05, Josh Stern wrote:
Max Horn
Software Developer
email: mailto:Max_Horn
phone: (+49) 6151-494890
At 23:13 Uhr +0200 09.10.2001, David Olofson wrote:
[…]
What,
if any, are the hidden gotchas there? I realize that
the event handling would need to be slightly modified.that’s probably the major gotcha. This is hard to do without
breaking compatibility, and it’s quite some work to do it in a useful
way.Another “gotcha” is that it is not possible to do this at all on some
of SDLs backends, e.g. fbcon. Of course in future SDL versions, this
shoudl just be an attribut of the backend that tells whether it is
capable of doing this or not.
OTOH, SDL already has some window manager calls, which are nonsense
without a WM. (However, it’s rather harmless to “emulate” them by doing
nothing, which is not the case with multiple window support.)
How about attempts to open more than one window just failing on
full-screen only targets? Makes sense to me, especially since the whole
thing would be an extension to the API anyway.
But there’s still this event system problem… heh
The only safe way I can see is adding a new set of event polling/waiting
etc calls, with an extra reference argument to get the event source info
- that’s the only way that won’t break binary compatibility with the old
event system. Of course, code using the old event calls would only see
events from the first window (or the ‘current’ window, perhaps?), but
that should be relatively safe, as new applications would be expected to
use the extended event API…
Actually, when Kobo Deluxe is “finished” (and if I don’t get sidetracked
again :-), I’ll return to a multimedia related project that needs
multiple window support. If that happens before SDL 1.3, I might decide
to hack multiwindow support for X, although it probably won’t be clean
enough for mainstream SDL.
//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 10 October 2001 01:35, Max Horn wrote:
On Tuesday 09 October 2001 22:05, Josh Stern wrote:
David Olofson wrote:
At 23:13 Uhr +0200 09.10.2001, David Olofson wrote:
[…]
What,
if any, are the hidden gotchas there? I realize that
the event handling would need to be slightly modified.that’s probably the major gotcha. This is hard to do without
breaking compatibility, and it’s quite some work to do it in a useful
way.Another “gotcha” is that it is not possible to do this at all on some
of SDLs backends, e.g. fbcon. Of course in future SDL versions, this
shoudl just be an attribut of the backend that tells whether it is
capable of doing this or not.OTOH, SDL already has some window manager calls, which are nonsense
without a WM. (However, it’s rather harmless to “emulate” them by doing
nothing, which is not the case with multiple window support.)How about attempts to open more than one window just failing on
full-screen only targets? Makes sense to me, especially since the whole
thing would be an extension to the API anyway.
But there’s still this event system problem… heh
The only safe way I can see is adding a new set of event polling/waiting
etc calls, with an extra reference argument to get the event source info
- that’s the only way that won’t break binary compatibility with the old
event system.
Yes, I had thought of that, and also that the extra reference
could be a WindowID so the same API could potentially
support event delivery to abstract sub-windows of a top-level window.
Of course, code using the old event calls would only see
events from the first window (or the ‘current’ window, perhaps?), but
that should be relatively safe, as new applications would be expected to
use the extended event API…
I was wondering about possible issues related to multi-threading.
Although the SDL documentation seems very adequate in general,
I found the descriptions of what type of thread usage is currently
supported to be more than a little confusing.
What is the best documentation for the current capability of SDL
in that area? Some of the on-line docs seem to say that all
SDL library calls must be made from the same thread (in which
case there is no issue), but other docs seem to contradict that.
Actually, when Kobo Deluxe is “finished” (and if I don’t get sidetracked
again :-), I’ll return to a multimedia related project that needs
multiple window support. If that happens before SDL 1.3, I might decide
to hack multiwindow support for X, although it probably won’t be clean
enough for mainstream SDL.
I’m interested in the possiblity of creating an open source QtSDL
(a version of Qt with SDL as OS dependency layer and multimedia
framework) - even though Qt is huge, its platform dependencies
are relatively small and isolated; qt-embedded already has versions
of all the graphics that draw directly a framebuffer abstraction,
though qt-embedded itself would be otherwise more work to port
than qt-x11 since it includes both client libraries and a window server
abstraction with Unix IPC between the two.> On Wednesday 10 October 2001 01:35, Max Horn wrote:
On Tuesday 09 October 2001 22:05, Josh Stern wrote:
[…]
The only safe way I can see is adding a new set of event
polling/waiting etc calls, with an extra reference argument to get
the event source info - that’s the only way that won’t break binary
compatibility with the old event system.Yes, I had thought of that, and also that the extra reference
could be a WindowID so the same API could potentially
support event delivery to abstract sub-windows of a top-level window.
Yeah, provided it’s an internal “handle style” thing, like "screen"
surface index or something… (You can have those for both “real” windows
and sub-windows, of course.)
Of course, code using the old event calls would only see
events from the first window (or the ‘current’ window, perhaps?), but
that should be relatively safe, as new applications would be expected
to use the extended event API…I was wondering about possible issues related to multi-threading.
Although the SDL documentation seems very adequate in general,
I found the descriptions of what type of thread usage is currently
supported to be more than a little confusing.
What is the best documentation for the current capability of SDL
in that area? Some of the on-line docs seem to say that all
SDL library calls must be made from the same thread (in which
case there is no issue), but other docs seem to contradict that.
The event system is thread-safe…
Anyway, it shouldn’t be an issue regardless - just add some (internal)
way of marking each event with it’s source ID, and then build on the
existing event system implementation. The old SDL event calls would skip
any events that are not from the current window, while the new API
returns all events, with their respective ID.
One could wrap the current event structure:
typedef struct
{
SDL_Event event;
int windowid;
} SDL_ExtEvent;
and then have the old API only show the ‘event’ field, while the new
event API returns the whole thing as is.
Actually, when Kobo Deluxe is “finished” (and if I don’t get
sidetracked again :-), I’ll return to a multimedia related project
that needs multiple window support. If that happens before SDL 1.3, I
might decide to hack multiwindow support for X, although it probably
won’t be clean enough for mainstream SDL.I’m interested in the possiblity of creating an open source QtSDL
(a version of Qt with SDL as OS dependency layer and multimedia
framework) - even though Qt is huge, its platform dependencies
are relatively small and isolated; qt-embedded already has versions
of all the graphics that draw directly a framebuffer abstraction,
though qt-embedded itself would be otherwise more work to port
than qt-x11 since it includes both client libraries and a window
server abstraction with Unix IPC between the two.
The reason why I want multiple window support is that I’m designing a new
GUI toolkit, specifically for multimedia applications, and in particular
audio and music applications. Fortunately, the API used for
GUI<->application communication is designed in a way that allows for easy
implementation in “direct call” settings as well as client/server style
arrangments - but SDL with multiple window support would be a bit easier
to play with, and non-portable code in the toolkit implementation
wouldn’t be 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 Wednesday 10 October 2001 02:35, Josh Stern wrote: