Separating Window Management from Display Surfaces

Hi,

Started looking at ParaGUI recently. Having noted that there is no
support for SDL 1.3, I started looking into what would need doing.

Along the way, I noticed that there is no strict separation of window
management and display surfaces within SDL. This is particularly
apparent when one starts to use OpenGL, which as no concept of window
management.

Now, on traditional (desktop) systems, ordinary drawing surfaces seem
intrinsically linked to the notion of windows and window management; on
Win32, an SDL drawing surface is analogous to the ‘client area’ of a
window, while on X11, the smallest ‘visible’ primitive is a window.

On many other platforms (e.g. svgalib) there is simply no concept of a
window at all.

For tradition systems, there is also the question of integration of SDL
drawing surfaces into fully-featured widgets sets/window managers (GTK+,
Qt etc).

By separation, I mean something like (pseudo code):

SDL_surface *disp = SDL_CreateDisplaySurf().

if (system_has_wm()) {
SDL_window *win = SDL_CreateWindow(disp);
}

if (system_has_wm()) {
// Set window to fill screen "Maximise"
SDL_FullScreenWindow(win);
} else {
// Set surface to fill whole screen
SDL_FullScreenDisplaySurface(disp);
}

Questions:

  1. Is the current state a result of expedience vs. rigour in early
    designs (i.e. it wasn’t really an important issue when SDL started), or
    is it a concious reflection of the practicalities of some underlying
    systems?

  2. Would the following benefits be realisable if a more strict
    separation of window management were implemented?

    a. Reduced library overhead on non-windowed systems (e.g. svgalib).
    b. Improved consistency of concepts between windowed/non-windowed
    systems.
    c. Improved ease of integration with other GUI libraries (e.g. GTK+).
    d. Improved consistency of concepts between OpenGL surfaces and
    ordinary SDL surfaces (and other surfaces).
    e. Reduced complexity of implementing multi-window support on windowed
    platforms.

Jitsu love,

Eddy

Hello !

Sorry, i don’t see the point here.
I am not that deep into SDL 1.3.

You can create n Nr. of Windows in
a Windowing environment or one Window
in env. such as SVGALIB for example.

You can create SDL Surfaces and SDL Textures
from them and then blit them on different windows.

What do you want more or else ?

Or is there any limitation that is not public ?
You can blit the same texture to different windows or not ?

CU

Hi,

Torsten Giebl wrote:

Hello !

Sorry, i don’t see the point here.
I am not that deep into SDL 1.3.

You can create n Nr. of Windows in
a Windowing environment or one Window
in env. such as SVGALIB for example.

In a non-windowed environment it isn’t a ‘window’ it’s just a display
surface. This is exactly what I’m getting at, the disconnect between
concepts. If you say ‘window’, people tend to think of title-bars and
borders, etc; it risks creating false expectation of supported
capabilities on non-windowed platforms.

The second issue is that someone using SDL may not WANT SDL to provide
window-management features. This goes to the question I raised about
integration of SDL into other window managers / widget sets.

That is, if creating a surface with SDL means creating a full-blown
managed window, it implies integration with something like GTK+ would be
more difficult.

Here is a UML diagram of the current conceptual behaviour of SDL (both
1.3 and 1.2):

±------+ ±-----+
|Surface| |Window|
±------+ ±-----+
^ ^
| |±----±-----+
|
±-------------+
|DisplaySurface|
±-------------+
^
|
±---------------+
|GLDisplaySurface|
±---------------+

That is, a display surface (one that is visible) includes (inherits) the
concepts of windows / window managment.

This implies the inhibition of the ability to keep a window and change
its contents (eg, switch the surface between true colour and 8-bit
palettised).

It seems to me, that it would be better (as outlined in the potential
benefits in my original post) for the conceptual structure to be like this:

   +-------+
   |Surface|
   +-------+
       ^
       |
+--------------+    +------+
|DisplaySurface|<>--|Window|
+--------------+    +------+
       ^
       |

±---------------+
|GLDisplaySurface|
±---------------+

That is, the concept of windowing is independent of display surfaces,
allowing a window to contain several (aggregation) display surfaces
during its lifetime (or even simultaneously).

Eddy

Grr…

I ALWAYS get aggregation/composition the wrong way round… should be:

 +--------------+    +------+
 |DisplaySurface|--<>|Window|
 +--------------+    +------+

Eddy

Edward Cullen wrote:> Hi,

Torsten Giebl wrote:

Hello !

Sorry, i don’t see the point here.
I am not that deep into SDL 1.3.

You can create n Nr. of Windows in
a Windowing environment or one Window
in env. such as SVGALIB for example.

In a non-windowed environment it isn’t a ‘window’ it’s just a display
surface. This is exactly what I’m getting at, the disconnect between
concepts. If you say ‘window’, people tend to think of title-bars and
borders, etc; it risks creating false expectation of supported
capabilities on non-windowed platforms.

The second issue is that someone using SDL may not WANT SDL to provide
window-management features. This goes to the question I raised about
integration of SDL into other window managers / widget sets.

That is, if creating a surface with SDL means creating a full-blown
managed window, it implies integration with something like GTK+ would be
more difficult.

Here is a UML diagram of the current conceptual behaviour of SDL (both
1.3 and 1.2):

±------+ ±-----+
|Surface| |Window|
±------+ ±-----+
^ ^
| |
±----±-----+
|
±-------------+
|DisplaySurface|
±-------------+
^
|
±---------------+
|GLDisplaySurface|
±---------------+

That is, a display surface (one that is visible) includes (inherits) the
concepts of windows / window managment.

This implies the inhibition of the ability to keep a window and change
its contents (eg, switch the surface between true colour and 8-bit
palettised).

It seems to me, that it would be better (as outlined in the potential
benefits in my original post) for the conceptual structure to be like this:

  +-------+
  |Surface|
  +-------+
      ^
      |

±-------------+ ±-----+
|DisplaySurface|<>–|Window|
±-------------+ ±-----+
^
|
±---------------+
|GLDisplaySurface|
±---------------+

That is, the concept of windowing is independent of display surfaces,
allowing a window to contain several (aggregation) display surfaces
during its lifetime (or even simultaneously).

Eddy


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hello !

But what is the representation
of a DisplaySurface on a system like for example Win32 or
Linux ?

If you want to have a DisplaySurface you can just create an Empty
Surface and blit everything to it. There would be no difference
between a DisplaySurface and a normal Surface.

When integrating SDL into GTK or other Toolkits,
you have two ways :

Blit everything into a surface and then
use a function from the Toolkit like draw_image (buffer,x,y)
or you can let the toolkit create a borderless integrated window
somehow and use that.

When the data is not updated 50times a second or so,
the first method works great.

CU