hello,
lately i had posted some ideas about letting SDL replace X.
(you remember “X over SDL” etc. ?)
i wanted SDL to support window management, multiple applications
accessing
the same display, …
because there were many people who didn’t want to blow up SDL with those
functionalities (they only want to have it as a game development
platform
and nothing more), i’ve spend many thoughts about creating something
like an
"Complex Direct Media Layer".
anyone who’d like to join me ?
bye,
ew.
You mean just a simple GUI library that runs on top of SDL?
At 05:58 PM 3/25/00 +0000, you wrote:
hello,
lately i had posted some ideas about letting SDL replace X.
(you remember “X over SDL” etc. ?)i wanted SDL to support window management, multiple applications
accessing
the same display, …because there were many people who didn’t want to blow up SDL with those
functionalities (they only want to have it as a game development
platform
and nothing more), i’ve spend many thoughts about creating something
like an
"Complex Direct Media Layer".anyone who’d like to join me ?
bye,
ew.
-Garrett WPI student majoring in Computer Science.
“The fastest way to succeed is to look as if you’re playing by somebody
else’s rules, while quietly playing by your own.” -Michael Konda
i wanted SDL to support window management, multiple applications
accessing
the same display, …Window management is being implemented, by me as it happens (albeit very
slowly). Don’t know what you mean about multiple applications accessing the
same display, that sounds nasty. If you mean turning SDL into a desktop
manager, don’t even go there, that’s not what it was designed for. (Plus,
crossplatform windowing APIs are not meant to be. That’s why we have Linux
with Alpha, PPC, and Sparc versions :-))bye,
ew.Cheers,
Nicholas
Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert----- Original Message -----
From: weigelt@nibiru.pauls.erfurt.thur.de (Enrico Weigelt)
To: sdl at lokigames.com
Date: Saturday, March 25, 2000 10:11 AM
Subject: [SDL] “Complex Direct Media Layer” ?
Window management is being implemented, by me as it happens (albeit very
slowly). Don’t know what you mean about multiple applications accessing
the
same display, that sounds nasty. If you mean turning SDL into a desktop
manager, don’t even go there, that’s not what it was designed for.
Not a desktop manager, just a desktop. The idea, as I understand it, is to
allow multiple applications to render into a communal space.
As far as I can tell, what you’re working on is allowing SDL programs to
create, destroy, and manage native windows in a cross-platform manner. What
this gentleman is proposing is to allow multiple discrete, managed regions
(windows, in fact) to exist within a single SDL surface.
In my opinion, it doesn’t have to mean butchering SDL. In fact, I don’t
think it necessarily means applying the old windowing paradigm to the
project. Maybe multiple rendering threads could be managed in a more
cooperative way, such as giving each thread a unique “layer” in a stack of
composited surfaces. Then a “desktop manager” could be layered above, for
the purpose of allowing users (and applications) to dictate the compositing
order, the opacity of each layer, etc.
(Plus,
crossplatform windowing APIs are not meant to be. That’s why we have Linux
with Alpha, PPC, and Sparc versions :-))
What does your window management code do, then?
MJP
Window management is being implemented, by me as it happens (albeit very
slowly). Don’t know what you mean about multiple applications accessing
the
same display, that sounds nasty. If you mean turning SDL into a desktop
manager, don’t even go there, that’s not what it was designed for.Not a desktop manager, just a desktop. The idea, as I understand it, is to
allow multiple applications to render into a communal space.… ah. So why reinvent the wheel? The Xfree86 folks have been doing this
for far longer than we have and have WAY more experience. If you’re talking
about a shared driver, so that I could run 3 apps and they’d all render into
one SVGAlib buffer, than I’d really just prefer to use X thanks.As far as I can tell, what you’re working on is allowing SDL programs to
create, destroy, and manage native windows in a cross-platform manner. What
this gentleman is proposing is to allow multiple discrete, managed regions
(windows, in fact) to exist within a single SDL surface.Actually, as it happens, the windowing code which I’m working on has an
emulated window management mode so that in the event of you trying to use a
windowed application in an environment where there is no native window
management, it’ll bang out some windows for you. Not multiple applications,
but definitely useful.In my opinion, it doesn’t have to mean butchering SDL. In fact, I don’t
think it necessarily means applying the old windowing paradigm to the
project. Maybe multiple rendering threads could be managed in a more
cooperative way, such as giving each thread a unique “layer” in a stack of
composited surfaces. Then a “desktop manager” could be layered above, for
the purpose of allowing users (and applications) to dictate the compositing
order, the opacity of each layer, etc.Threadsafing, bugger. (writes note!)
(Plus,
crossplatform windowing APIs are not meant to be. That’s why we have
Linuxwith Alpha, PPC, and Sparc versions :-))
What does your window management code do, then?
Let me rephrase that! What I meant to say by crossplatform windowing APIs is
that I can create a program which can act as a multiplatform desktop
environment… given C source, I can recompile so that it will run on any
platform which supports my desktop window manager. Sounds cool, but
unfortunately there are really only two platforms which have enough of a
non-GUI back end to support this kind of operation: Linux and DOS. Win + Mac
are far too tied up in their own desktop management.MJP
Nicholas
Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert----- Original Message -----
From: mjpeck@mindspring.com (Michael Peck)
To: sdl at lokigames.com
Date: Saturday, March 25, 2000 9:56 PM
Subject: Re: [SDL] “Complex Direct Media Layer” ?
Nicholas Vining wrote:>
> >Not a desktop manager, just a desktop. The idea, as I understand it, is to > >allow multiple applications to render into a communal space. > > ... ah. So why reinvent the wheel? The Xfree86 folks have been doing this > for far longer than we have and have WAY more experience. If you're talking > about a shared driver, so that I could run 3 apps and they'd all render into > one SVGAlib buffer, than I'd really just prefer to use X thanks. whel => new wheel with rim+tire ;-)-----Original Message-----
From: Michael Peck
To: sdl at lokigames.com
Date: Saturday, March 25, 2000 9:56 PM
Subject: Re: [SDL] “Complex Direct Media Layer” ?
yeah. it would have much of the functionality of X, but with some big
differences :
a) platform idependent.
b) philosophy of X: the display is somewhere on the net, but perhaps
local.
philosophy of CDML: the display is local, but perhaps somewhere on
the net …
another important concept of CDML would be:
let the server do as much as possible
=> simple display+window management, high acceleration, 3D-rendering,
audio stuff, …
Enrico Weigelt wrote:
yeah. it would have much of the functionality of X, but with some big
differences :a) platform idependent.
b) philosophy of X: the display is somewhere on the net, but perhaps
local.
philosophy of CDML: the display is local, but perhaps somewhere on
the net …another important concept of CDML would be:
let the server do as much as possible
=> simple display+window management, high acceleration, 3D-rendering,
audio stuff, …
So funny… The way I see people using SDL (and the way SDL is made),
you’d save one context switch with this. But of course, the game itself
would imply a dozen of context switches… duh…
X with some kind of direct rendering will get you all you want. Maybe
what we need is direct rendering support for 2D primitives (a “Really
Direct Graphic Access” 
), and you’ll be fine.
With DGA and DGA2, accelerated functions are executed by the server, in
a matter similar to indirect GLX. All DGA really gives you is direct
access to the framebuffer (which is not very useful in itself),
everything else is like indirect GLX. We need a “Direct DGA”, and this
CDML thing would be next to useless after that.–
Pierre Phaneuf
Systems Exorcist
X with some kind of direct rendering will get you all you want. Maybe
what we need is direct rendering support for 2D primitives (a “Really
Direct Graphic Access”
Actually I’ve been thinking along these lines for a while. The architecture
is simple in theory, if not in implementation. You want a small kernel
module that knows how to dispatch DMA buffers to your particular card,
sitting underneath a user-space library that builds said buffers in response
to drawing API calls. (this is basically how Windows GDI works, BTW).
But you have to ask yourself, what sort of interface do you really want?
This approach gives you hardware-direct accelerated fills and blits across
the PCI bus. Maybe someone with more experience can chime in here, but I’m
worried that you’d run out of memory bandwidth even at modest resolutions
(hmm I wonder if a card could handle, say, blits totalling 1024x768, with
alpha and overdraw, at 60fps?).
You could get tricky and try storing some bitmaps on the card’s local
memory… Problem is, this gets VERY hairy when more than one client is
running at once. Correct and speedy multiplexing of the graphics memory is
anything but a simple task- look at the huge infrastructure that DRI uses to
deal with this (and IMHO it’s still a kludge =)
The “ideal” solution is to change the hardware - unifying graphics memory
with system memory (as in SGI systems) makes sharing the hardware a lot
easier. Adding a full MMU with page tables to the graphics card also makes a
lot of sense (see Carmack’s recent plan update)… Still, as I think about
it, maybe DMA is fast enough on PC graphics hardware- anyone got numbers on
this?
Dan
Dan Maas wrote:
X with some kind of direct rendering will get you all you want. Maybe
what we need is direct rendering support for 2D primitives (a “Really
Direct Graphic Access”Actually I’ve been thinking along these lines for a while. The architecture
is simple in theory, if not in implementation. You want a small kernel
module that knows how to dispatch DMA buffers to your particular card,
sitting underneath a user-space library that builds said buffers in response
to drawing API calls. (this is basically how Windows GDI works, BTW).
The DRI that was made for 3D hardware accelerator has the same
principles, has a kernel module that does that, authenticate clients
with the X server and manages resource sharing between clients. This
should be extended to 2D primitives.
But you have to ask yourself, what sort of interface do you really want?
This approach gives you hardware-direct accelerated fills and blits across
the PCI bus. Maybe someone with more experience can chime in here, but I’m
worried that you’d run out of memory bandwidth even at modest resolutions
(hmm I wonder if a card could handle, say, blits totalling 1024x768, with
alpha and overdraw, at 60fps?).
No, even with non-PIO blits, it’s rather easy to saturate. But it makes
the difference between 320x240 or 640x480 in 8 bit PseudoColor and
640x480 in 16 bit or maybe even 800x600 if the application permits it,
with good framerates.
You could get tricky and try storing some bitmaps on the card’s local
memory… Problem is, this gets VERY hairy when more than one client is
running at once. Correct and speedy multiplexing of the graphics memory is
anything but a simple task- look at the huge infrastructure that DRI uses to
deal with this (and IMHO it’s still a kludge =)
Yes, DRI is a kludge in a way (ok, maybe in more than a way!), but it
works. We should steal this infrastructure (hey, they took the trouble
to make it work, let’s use it!).
The “ideal” solution is to change the hardware - unifying graphics memory
with system memory (as in SGI systems) makes sharing the hardware a lot
easier. Adding a full MMU with page tables to the graphics card also makes a
lot of sense (see Carmack’s recent plan update)… Still, as I think about
it, maybe DMA is fast enough on PC graphics hardware- anyone got numbers on
this?
Hmm, ccNUMA… Sweeeet… :-)–
Pierre Phaneuf
Systems Exorcist
