Multiple SDL Windows again

ANOQ_of_the_Sun · April 26, 2001, 8:45am

Hello!

Earlier I heard rumors that SDL with support for multiple
windows was to be done no earlier than SDL 1.3.
And also:

Sam wrote:

based on what we’ve learned over the past four years.
The architecture design is partially done, and we’ll start prototyping
the design soon. As soon as there’s a working framework, we’ll make it
publicly available for comment and contributions. This new framework
has about a year or a year and a half before we anticipate it being
ready for stable release. We anticipate this framework being the next
generation SDL 2.0 API.

But I would really really like to use multiple windows with SDL -
so, if I implement it - will I just get flamed or will it end up
in the current-generation public releases of SDL?

If I’m going to implement this I would go for the quick and
dirty way:

*) Allow SDL_SetVideoMode to be called multiple times
*) Add a SDL_CloseScreen function for an SDL_Surface
returned from SetVideoMode.
*) Only support it for non-fullscreen windows (i.e. desktop windows)
*) Possibly add / modify the necessary windowmanager functions.
*) Probably only implement it for Windows for now
(and someone else currently have my X11-book too)

If there are any hints on where I should look
in the code - I would love to know

Cheers> A: SDL 1.3 will be a near full rewrite of the SDL functionality,

http://www.HardcoreProcessing.com

Mattias_Engdegard · April 26, 2001, 9:10am

But I would really really like to use multiple windows with SDL -
so, if I implement it - will I just get flamed or will it end up
in the current-generation public releases of SDL?

it’s not a question of implementation, anyone can do that. it’s a question
of design

It sounds like you really don’t want to use SDL, since SDL is an
abstraction layer for a framebuffer. A windowing user-interface toolkit
like gtk or qt would probably serve you much better. You can also use a
separate process for each window

Xavier_Le_Pasteur · April 26, 2001, 10:31am

However, will you support multiple SDL windows in SDL 1.3 as
rumored or not ?

Personnaly I prefer that you kept the concept of the framebuffer
and kept SDL with a single window through the further SDL versions…–

Xavier Le Pasteur
@Xavier_Le_Pasteur

But I would really really like to use multiple windows with SDL -
so, if I implement it - will I just get flamed or will it end up
in the current-generation public releases of SDL?

it’s not a question of implementation, anyone can do that. it’s a question
of design

It sounds like you really don’t want to use SDL, since SDL is an
abstraction layer for a framebuffer. A windowing user-interface toolkit
like gtk or qt would probably serve you much better. You can also use a
separate process for each window

Sam_Hart · April 26, 2001, 4:02pm

Earlier I heard rumors that SDL with support for multiple
windows was to be done no earlier than SDL 1.3.

If I’m going to implement this I would go for the quick and
dirty way:

*) Allow SDL_SetVideoMode to be called multiple times
*) Add a SDL_CloseScreen function for an SDL_Surface
returned from SetVideoMode.
*) Only support it for non-fullscreen windows (i.e. desktop windows)
*) Possibly add / modify the necessary windowmanager functions.
*) Probably only implement it for Windows for now
(and someone else currently have my X11-book too)

You can already do multiple non-fullscreen (desktop) windows using SDL using
simple IPC. I wrote an example of this a bit ago, and I know it works in POSIX
environments (I’m sure, with tweaking, you should be able to do the same in
non-POSIX environments).

My example can be found on my demo page (it’s the first SDL example listed):
http://www.geekcomix.com/snh/files/demos/

Now being able to do multiple /fullscreen/ windows (i.e., some sort of multiple
window ports within a single surface, without worrying having to impliment
yourself using multiple surfaces) would be very useful IMHO, especially in
non-windowmanagement environments (such as the linux framebuffer ;-)On Thu, 26 Apr 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/ >

slouken · April 26, 2001, 4:16pm

However, will you support multiple SDL windows in SDL 1.3 as
rumored or not ?

Personnaly I prefer that you kept the concept of the framebuffer
and kept SDL with a single window through the further SDL versions…

SDL 1.3 will support multiple windows as a natural extension of
multi-head support.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

icculus · April 26, 2001, 8:47pm

If I’m going to implement this I would go for the quick and
dirty way:

*) Allow SDL_SetVideoMode to be called multiple times

This breaks a LOT of programs that use SDL_SetVideoMode() multiple times
to switch video modes/resolutions/window sizes, and assume the old window
is going away to make way for the new.

–ryan.

Lloyd_Dupont · April 26, 2001, 7:01pm

may be they want multiple windows in WindowServer meaning !!!
wich can be nested…
and have OpenGL inside a a non-OpenGL window…

ANOQ_of_the_Sun · April 27, 2001, 4:37pm

Mattias Engdeg?rd wrote:

it’s not a question of implementation, anyone can do that. it’s a question
of design

It sounds like you really don’t want to use SDL, since SDL is an
abstraction layer for a framebuffer. A windowing user-interface toolkit
like gtk or qt would probably serve you much better. You can also use a
separate process for each window

Xavier Le Pasteur wrote:

Personnaly I prefer that you kept the concept of the framebuffer
and kept SDL with a single window through the further SDL versions…

Samuel Hart wrote:

You can already do multiple non-fullscreen (desktop) windows using SDL using
simple IPC. I wrote an example of this a bit ago, and I know it works in POSIX
environments (I’m sure, with tweaking, you should be able to do the same in
non-POSIX environments).

Well - I didn’t mean to bring up the old discussion again, but…

*) Yes I do want to use SDL - so that I can have graphics in a
crossplatform way.
*) No I don’t want to use a UI-toolkit - I want to write one…
*) Using IPC for every single popup menu, tooltip etc. is not a good
option.

“Ryan C. Gordon” wrote:

This breaks a LOT of programs that use SDL_SetVideoMode() multiple times
to switch video modes/resolutions/window sizes, and assume the old window
is going away to make way for the new.

*) OK - so I will just have to add a flag - like
SDL_EXTRASCREEN or something.

But it seems that I’m getting flamed for this already…
but I would really really like to have this feature ASAP

Cheers–
http://www.HardcoreProcessing.com

David_Hedbor · April 27, 2001, 5:16pm

Anoq of the Sun writes:

*) No I don’t want to use a UI-toolkit - I want to write one…
*) Using IPC for every single popup menu, tooltip etc. is not a good
option.

Why on earth would you have a single SDL screen for each popup menu
and what not? Windows etc would be surfaces, but not screens. Just
create a surface for each thing you need and blit it upon the actual screen.–
[ Below is a random fortune, which is unrelated to the above message. ]
Don’t get even – get odd!

ANOQ_of_the_Sun · April 28, 2001, 3:23pm

David Hedbor wrote:

Why on earth would you have a single SDL screen for each popup menu
and what not? Windows etc would be surfaces, but not screens. Just
create a surface for each thing you need and blit it upon the actual screen.

Well, in many cases this would be OK - but only until the
popup menus get sufficiently big so that they have to
extend beyond the borders of the window - or if, say,
the window is at the bottom of the screen and you
need to popup the menu upwards instead of downwards
to be able to see it. So the only solution which is
general enough is a new window for each popup-menu…

and then comes all the problems with save-unders
for efficiency etc. - so maybe some day I will need
to add flags for that to SDL too… but I think this
would also be a good thing to have control over in SDL
anyway.

“Ryan C. Gordon” wrote:

I’m not flaming you…I just wanted you to be aware of what existing
programs do. If you implement it, that’d be cool.

OK - maybe I sounded too harsh - sorry - I didn’t mean to.
And I know that your point was very relevant
But I hope the SDL_EXTRASCREEN flag would be adequate
for solving the problem.

But is the solution I’m talking about "accepted"
as something worthy to be put into the official
releases? Sam?

Cheers–
http://www.HardcoreProcessing.com

slouken · April 28, 2001, 3:42pm

But is the solution I’m talking about "accepted"
as something worthy to be put into the official
releases? Sam?

SDL will never be designed to function as a UI toolkit. The multiple
window support will be designed for the general multi-head case.
However, SDL does and will integrate with other GUI toolkits, like
GTk and Qt, which provide the kind of functionality you desire.

You are welcome to hack the support you want into SDL and distribute
the modified version with your program. If it works well, I’ll look
at it when implementing multi-window support in SDL 1.3.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

David_Snopek · April 28, 2001, 4:32pm

Anoq of the Sun wrote:

David Hedbor wrote:

Why on earth would you have a single SDL screen for each popup menu
and what not? Windows etc would be surfaces, but not screens. Just
create a surface for each thing you need and blit it upon the actual screen.

Well, in many cases this would be OK - but only until the
popup menus get sufficiently big so that they have to
extend beyond the borders of the window - or if, say,
the window is at the bottom of the screen and you
need to popup the menu upwards instead of downwards
to be able to see it. So the only solution which is
general enough is a new window for each popup-menu…

This can’t be how real GUI’s do it!?! That just sounds so wasteful to
me. Maybe it would be better to hack in support for drawing to the root
window so you can draw past the window borders??

-- David Snopek

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

David_Olofson · April 29, 2001, 6:14am

Anoq of the Sun wrote:

David Hedbor wrote:

Why on earth would you have a single SDL screen for each popup menu
and what not? Windows etc would be surfaces, but not screens. Just
create a surface for each thing you need and blit it upon the actual
screen.

Well, in many cases this would be OK - but only until the
popup menus get sufficiently big so that they have to
extend beyond the borders of the window - or if, say,
the window is at the bottom of the screen and you
need to popup the menu upwards instead of downwards
to be able to see it. So the only solution which is
general enough is a new window for each popup-menu…

This can’t be how real GUI’s do it!?! That just sounds so wasteful to
me.

Wasteful or not; that is how most toolkits do it, as there is no other way
of rendering outside a window… And it’s not really that bad, if implemented
properly. Have a look at SDL’s clipping, add some window management
functionality to keep track of dirty areas, and you get the idea.

Maybe it would be better to hack in support for drawing to the root
window so you can draw past the window borders??

Well, yeah, you can do that on some targets (like X and Windows), but

1) You still cannot render on top of other windows on some
   targets; only on the background/root window - which is *not*
   the same thing as the Win32 HDC 0 "window".

2) Who are you going to ask to restore the previous
   background afterwards?

3) You can't save the background yourself either, as that may
   break anything that's going on in the background.

4) You can't prevent other applications from overdrawing your
   menu without you knowing about it.

Of course, all that can be fixed with proper support from the rendering
target. That support exists, and is provided in the form of an abstraction
called a “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 Saturday 28 April 2001 18:32, David Snopek wrote:

David_Olofson · April 29, 2001, 6:24am

That method forces you to use the dreaded MDI style design - an annoying GUI
design style that was invented in the dark (pre-multitasking) ages, and for
some reason is still utilized on some platforms, probably because it can make
the screen layout slightly less confusing to absolute beginners…

As to menues, it makes the larger ones useless, unless you’re effectivey
running the application in full screen size, which makes the use of windowed
somewhat pointless in the first place.

//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 27 April 2001 19:16, David Hedbor wrote:

Anoq of the Sun writes:

*) No I don’t want to use a UI-toolkit - I want to write one…
*) Using IPC for every single popup menu, tooltip etc. is not a good
option.

Why on earth would you have a single SDL screen for each popup menu
and what not? Windows etc would be surfaces, but not screens. Just
create a surface for each thing you need and blit it upon the actual
screen.

icculus · April 29, 2001, 11:47pm

This can’t be how real GUI’s do it!?! That just sounds so wasteful to
me.

Wasteful or not; that is how most toolkits do it, as there is no other way
of rendering outside a window… And it’s not really that bad, if implemented
properly. Have a look at SDL’s clipping, add some window management
functionality to keep track of dirty areas, and you get the idea.

This isn’t really how most GUIs do it.

(Generally speaking) At the windowing system level, there is an abstract
concept of a “window”, which isn’t nearly as resource intensive as, say,
an Xterm or Netscape’s “window,” which are comprised of several
windowing system windows.

Different systems call these different things: controls, components,
widgets. They are, individually, designed for piling next to and on top of
each other in large quantities. They each get individual events
(mouseovers, etc), and their rendering doesn’t overwrite the graphical
contents of any other overlapping widgets.

An SDL window is much, much heavier than one of these, as it is already a
collection of widgets (titlebar, maximize button, surface, etc). Each SDL
window gets it’s own events and handles it’s own redraw, but in terms of a
UI toolkit, this is accidental.

Just wanted to make that distinction. See my next post about using SDL for
a ui toolkit.

–ryan.

icculus · April 29, 2001, 11:59pm

Well, in many cases this would be OK - but only until the
popup menus get sufficiently big so that they have to
extend beyond the borders of the window - or if, say,
the window is at the bottom of the screen and you
need to popup the menu upwards instead of downwards
to be able to see it. So the only solution which is
general enough is a new window for each popup-menu…

Assuming that the EXTRAWINDOW flag is a viable approach to extending SDL
(I’ll leave that to Sam to comment upon), then what you would want to do
is something like how Java’s Swing class does it.

You have a few HEAVYWEIGHT windows: top level, framed windows, popups and
pulldown menus, etc. Each of these is a SDL surface created with this
hypothetical EXTRAWINDOW flag.

Every thing else is a LIGHTWEIGHT window. They can be offscreen surfaces,
or whatever, but their only physical representation is when it is rendered
inside a heavyweight window. This means you need to manage rendering
overlap of lightweights, and catch mouse/keyboard/etc events on the
heavyweight and see that they make it to the correct lightweight
component.

This IS doable. With something like EXTRAWINDOW, it could even be done
with SDL.

The question though, is what would be the worth? There are UI kits for SDL
(although they don’t allow popups past the edge of the screen surface,
etc) if you just want some basic UI functionality. There are portable
solutions (gtk, Qt, wxWindows, Swing) if you want that.

If you just want to tinker, the heavyweight/lightweight approach would be
fun to code, but would be a lot of work for (again) something of less
pratical value than it should be worth.

(shrug)

–ryan.

David_Olofson · April 30, 2001, 8:28am

This can’t be how real GUI’s do it!?! That just sounds so wasteful to
me.

Wasteful or not; that is how most toolkits do it, as there is no other
way of rendering outside a window… And it’s not really that bad, if
implemented properly. Have a look at SDL’s clipping, add some window
management functionality to keep track of dirty areas, and you get the
idea.

This isn’t really how most GUIs do it.

(Generally speaking) At the windowing system level, there is an abstract
concept of a “window”, which isn’t nearly as resource intensive as, say,
an Xterm or Netscape’s “window,” which are comprised of several
windowing system windows.

I was thinking in rendering terms, and I was taking for granted that no one
was talking of “real” windows. (With title bar, borders etc.)

Different systems call these different things: controls, components,
widgets. They are, individually, designed for piling next to and on top of
each other in large quantities. They each get individual events
(mouseovers, etc), and their rendering doesn’t overwrite the graphical
contents of any other overlapping widgets.

An SDL window is much, much heavier than one of these, as it is already a
collection of widgets (titlebar, maximize button, surface, etc). Each SDL
window gets it’s own events and handles it’s own redraw, but in terms of a
UI toolkit, this is accidental.

Right; as SDL looks now, the closest you can get is a borderless window.
However, whether or not that’s heavier than a “low level window” (or drawing
context, or whatever targets call it) depends on the implementation… The
SDL_Surface abstraction would be very similar for “real” windows and the low
level ones.

//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 Monday 30 April 2001 01:47, Ryan C. Gordon wrote:

David_Olofson · April 30, 2001, 8:46am

Well, in many cases this would be OK - but only until the
popup menus get sufficiently big so that they have to
extend beyond the borders of the window - or if, say,
the window is at the bottom of the screen and you
need to popup the menu upwards instead of downwards
to be able to see it. So the only solution which is
general enough is a new window for each popup-menu…

Assuming that the EXTRAWINDOW flag is a viable approach to extending SDL
(I’ll leave that to Sam to comment upon), then what you would want to do
is something like how Java’s Swing class does it.

You have a few HEAVYWEIGHT windows: top level, framed windows, popups and
pulldown menus, etc. Each of these is a SDL surface created with this
hypothetical EXTRAWINDOW flag.

Every thing else is a LIGHTWEIGHT window. They can be offscreen surfaces,
or whatever, but their only physical representation is when it is rendered
inside a heavyweight window. This means you need to manage rendering
overlap of lightweights, and catch mouse/keyboard/etc events on the
heavyweight and see that they make it to the correct lightweight
component.

This IS doable. With something like EXTRAWINDOW, it could even be done
with SDL.

This is exactly the approach I was talking about some time ago, although with
different terminology.

The question though, is what would be the worth? There are UI kits for SDL
(although they don’t allow popups past the edge of the screen surface,
etc) if you just want some basic UI functionality. There are portable
solutions (gtk, Qt, wxWindows, Swing) if you want that.

If you want to use widgets integrated with the SDL display when in fullscreen
mode, and in separate windows when in windowed mode, you have to use at least
two toolkits on most platforms - and probably more if you want to support
more than one platform. At that point, it can almost be viable to hack a
custom toolkit, if it solves that problem… heh

If you just want to tinker, the heavyweight/lightweight approach would be
fun to code, but would be a lot of work for (again) something of less
pratical value than it should be worth.

OTOH, if SDL 2.0 is going to have “advanced clipping”, the lightweight
windows are almost there already, except for the event dispatching part.
(IMHO, that part should be managed by the toolkit for maximum flexibility.
Hardcoding it into the SDL event system doesn’t make much sense, as it’s the
toolkit that should decide how mouse capture, keyboard focus etc is handled.)

Lightweight windows could be presented as a structured alternative to
changing the cliprect, also handling overlapping correctly. It might even be
possible to implement that as an optional low level window manager library,
that just uses the advanced clipping features in a more structured way than
just building raw clipping regions directly.

As to the heavyweight part; I don’t know what the SDL 2.0 API will look like,
but it seems reasonable that supporting multiple windows on windowed targets
would be an almost free bonus as soon as the fullscreen multihead, stereo,…
stuff is in place.

//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 Monday 30 April 2001 01:59, Ryan C. Gordon wrote:

ANOQ_of_the_Sun · May 11, 2001, 6:28pm

“Ryan C. Gordon” wrote:

Assuming that the EXTRAWINDOW flag is a viable approach to extending SDL
(I’ll leave that to Sam to comment upon), then what you would want to do
is something like how Java’s Swing class does it.

You have a few HEAVYWEIGHT windows: top level, framed windows, popups and
pulldown menus, etc. Each of these is a SDL surface created with this
hypothetical EXTRAWINDOW flag.

Every thing else is a LIGHTWEIGHT window. They can be offscreen surfaces,
or whatever, …

This heavyweight versus lightweight thing sounds pretty
nice - but as I see it right now, an SDL_Surface is
a “lightweight” window (it can also be offscreen etc.
if you use SDL_AllocSurface etc.). If however the
surface was created with SDL_SetVideoMode, then
it will be a physical window too - like a "heavyweight"
one…

But regarding the multiple window support in SDL -
the current design of the eventsystem in SDL doesn’t
support events to be dispatched to different windows -
I’m thinking especially of mouseevents here.
How would you know in which window a mouse move
(or whatever) event actually occurred?

So, I’m thinking of another approach of doing this…

Add some functions to SDL that allows it to work
with / co-exist with the native backend of the
OS. I know it’s ugly and platformdependent etc. -
but it would really be useful in many cases.

(also, see the post of
"Raw Nerves" ,
subject: “win32 API for an SDL window application.”).

And it means that you have access to anything
that you would otherwise have in the native
OS that you’re using! Esentially making sure
that there are no “limitations” to using SDL…
In a sense, it would make SDL more “open”.

I would, however, only be insterested in ( = have time
for) implementing a win32 version of this feature -
at least for now.

You would probably only need a few functions
to “assign” an SDL_Surface to a native window -
and vice versa. Of couse it must be convenient
to do this so that you retain framebuffer formats
etc.

With something like this (assuming that somebody
eventually writes something similar for all supported
OS’es) - people could make extra separate libraries
for SDL with as many weird OS-specific features as
desired and with support for as many platforms as
time / possibilities permit.

I don’t know when / if I’ll have time to hack
something like this up - but at some point I might
just do it and call it a “suggestion for new features”
Any comments are most welcome though

Cheers–
http://www.HardcoreProcessing.com

David_Olofson · May 11, 2001, 10:09pm

[…]

But regarding the multiple window support in SDL -
the current design of the eventsystem in SDL doesn’t
support events to be dispatched to different windows -
I’m thinking especially of mouseevents here.
How would you know in which window a mouse move
(or whatever) event actually occurred?

Yeah… However, it’s not as simple as “send all events to the window under
the mouse pointer…”

The usual solution seems to be to add the concepts “focused window”, “mouse
capture” and a few other, rather simple “filters”, and then provide an API
for that, for toolkits and to some extent, applications, to use. Every window
would have some kind of “event port”.

Idea: If a window isn’t equipped with an event port, the events can fall
through to it’s parent, or something… Would make it possible to use the
same window abstraction like a more lightweight overlapping + clipping
rendering control primitive; an advanced cliprect object.

So, I’m thinking of another approach of doing this…

Add some functions to SDL that allows it to work
with / co-exist with the native backend of the
OS. I know it’s ugly and platformdependent etc. -
but it would really be useful in many cases.

(also, see the post of
"Raw Nerves" ,
subject: “win32 API for an SDL window application.”).

And it means that you have access to anything
that you would otherwise have in the native
OS that you’re using! Esentially making sure
that there are no “limitations” to using SDL…
In a sense, it would make SDL more “open”.

I would, however, only be insterested in ( = have time
for) implementing a win32 version of this feature -
at least for now.

You would probably only need a few functions
to “assign” an SDL_Surface to a native window -
and vice versa. Of couse it must be convenient
to do this so that you retain framebuffer formats
etc.

I don’t see how this could be done using a portable API…

With something like this (assuming that somebody
eventually writes something similar for all supported
OS’es) - people could make extra separate libraries
for SDL with as many weird OS-specific features as
desired and with support for as many platforms as
time / possibilities permit.

…then again, that might not be the point? It does make some sense to build
some low level hooks into SDL, but I’m not sure it makes much sense to this
low a level.

Considering that there already are things like flags for borderless windows,
fullscreen mode etc, it sounds like supporting multiple screen surfaces is
just another step - which could be extended with some way of snapping in
window managers for fullscreen modes and that kind of stuff. (In that case,
the fullscreen window manager would do the event dispatching, pretty much
like the target’s WM does with “normal” windows. No difference for SDL
applications.)

It would be logical that these fullscreen window managers would show up
behind the existing window manager API, of course. In fact, the current SDL
WM code could probably use the same “plugin” API as the fullscreen window
managers.

It might be a good idea to make sure that “WM inside WM” is possible, though.
Most importantly, that would allow a custom WM to be used inside a normal
window on windowed target.

I don’t know when / if I’ll have time to hack
something like this up - but at some point I might
just do it and call it a “suggestion for new features”
Any comments are most welcome though

Well, you got some above.

BTW, note that I’m thinking in terms of what may make sense for SDL 1.3, but
might be messy to hack into 1.2. Without multiple screen surface support and
complex region clipping, only half of the features can be done right… And
why mess with it if it’s going to be done right anyway?

It’s probably possible to come up with some shortcut, but I’m failing to see
one that both provides something truly useful, and is still clean and
portable…

//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 11 May 2001 20:28, Anoq of the Sun wrote: