X-platform widget library

hello, everyone

let me start off by saying that i am a big fan of sdl.

ok. here it is:
i want to use sdl as common ground for a gfx lib, similiar to gtk and such,
that is cross platform (really just win32 and linux/x, but the thers are
welcome). is this a wise choice?

one thing that prompted me to ask this is the situation of multiple frame
windows (wnds on the desktop). i dont really think this is supported. how
hard would it be for this to be supported? would i be better off coding
this x-platform lib myself?

also, one last question before i go:

can i resize an [sdl] window without losing its contents? 9ie: how well doe
sdl resond to WM_RESIZE (on win32))?–
etoffi

i want to use sdl as common ground for a gfx lib, similiar to gtk and such,
that is cross platform (really just win32 and linux/x, but the thers are
welcome). is this a wise choice?

SDL is not really a gfx library. It contains the setup code, but there is
no routine to draw a line for example; something which I would expect from
a gfx library. There are (or at least there is one) graphics library for
SDL though.

Multiple frame windows are coming to SDL 2 (maybe 1.3 too?)

can i resize an [sdl] window without losing its contents? 9ie: how well doe
sdl resond to WM_RESIZE (on win32))?

I don’t know. This made me wonder: WHat happens to OpenGL texturee and
displaylists when I resize OpenGL SDL window? It is not documented; last
time I tried my textures went all wrong…

– Timo Suoranta – @Timo_K_Suoranta

hello, everyone

let me start off by saying that i am a big fan of sdl.

ok. here it is:
i want to use sdl as common ground for a gfx lib, similiar to gtk and such,
that is cross platform (really just win32 and linux/x, but the thers are
welcome). is this a wise choice?

Not sure for the general case, but I’m planning to do something like that for
MAIA… (See .sig.)

The design goals for that toolkit are quite different from “normal” toolkits
like GTK+ and Qt, as it’s meant for the kind of GUIs used for VST (Win32 and
MacOS) and DirectX audio plugins. That is, lots of chrome and detailed design
time control over look and feel, but limited support for scaling, themes,
widget “packing” and other features that tend to break design and rendering
quality.

In short, it’s going to be more like Shockwave than a traditional toolkit.

one thing that prompted me to ask this is the situation of multiple frame
windows (wnds on the desktop). i dont really think this is supported. how
hard would it be for this to be supported?

This has been discussed some on the list recently, mostly by me and “Anoq of
the Sun” . Can’t say how hard it would be to
actually implement, but someone will probably try to do it sooner or later.
That is, unless SDL 1.3 will do it, and is in a usable state soon enough. :slight_smile:

would i be better off coding this x-platform lib myself?

Depends… Probably not, if SDL fits the bill well enough. It’s most probably
less work to hack SDL than to code something from scratch, at least if you
need more than the absolute basic stuff.

Personally, I absolutely need alpha blending (for translucency effects and
antialiasing) and decent rendering performance for the MAIA GUI solution, and
the most important features are related to RGB image blitting, so SDL seems
to fit rather well. There are drawing primitive libs and stuff for SDL, to
deal with more “traditional” GUI toolkit rendering methods as well.

also, one last question before i go:

can i resize an [sdl] window without losing its contents? 9ie: how well doe
sdl resond to WM_RESIZE (on win32))?

I’m not sure what exactly happens on Win32, but regardless of platform, you
have to reinitialize the video subsystem with the new size. I’d guess SDL
tells Win32 not to clear out the window automatically, but nevertheless,
you’ll have to repaint the “screen” surface sooner or later anyhow, even if
you may not have to do it right after the resize. (Might work to reinit SDL
video, and then, if the window got larger, first render only the part that
just became visible, followed by an SDL_UpdateRect() call to blit only that
part into the window. Not sure if you can rely on that to work on all
targets, though.)

//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.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 28 May 2001 12:43, etoffi jones wrote:

The design goals for that toolkit are quite different from "normal"
toolkits
like GTK+ and Qt, as it’s meant for the kind of GUIs used for VST (Win32
and
MacOS) and DirectX audio plugins. That is, lots of chrome and detailed
design
time control over look and feel, but limited support for scaling, themes,
widget “packing” and other features that tend to break design and
rendering
quality.

Are you about to use pixels as measurement? If so, do you think that’s
really wise with next generation high resolution LCD displays around the
corner? There will be time in not so distant future (I would guess 1 or 2
years) when we have these 100 dpi CRT displays and 200+ dpi LCD displays.
The only reasonable solution is to use automatically scaling windows (like
GTK) or to use real world measurement (like mm, cm) instead of pixels. If
that toolkit becomes successful I wouldn’t want such problems with different
resolution displays.

  • Mikko

The design goals for that toolkit are quite different from "normal"
toolkits
like GTK+ and Qt, as it’s meant for the kind of GUIs used for VST (Win32
and
MacOS) and DirectX audio plugins. That is, lots of chrome and detailed
design
time control over look and feel, but limited support for scaling, themes,
widget “packing” and other features that tend to break design and
rendering quality.

Are you about to use pixels as measurement?

Yes and no; I’m going to use a floating point, sub pixel accurate coordinate
system where a “canvas” normally has a range of [0.0, 1.0[ for each axis.
(I’m probably going to include a scale + offset transformation.)

However, the general idea is that GUIs are to be constructed from images,
normally without scaling and rotation, as that isn’t technically possible
to do with acceptable quality.

If so, do you think that’s
really wise with next generation high resolution LCD displays around the
corner?

Well, wise or not; it’s the only way to get it to look real good, according
to professional audio plugin/application GUI designers. Scaling detailed
bitmap images just don’t work. Just have a look at any 3D game with properly
processed textures; they’re all “blurred” to some extent to avoid the
artifacts of the bilinear interpolation done by the 3D cards. More advanced
forms of scaling and rotation doesn’t improve the situation significantly in
this respect, so it’s not really a matter of CPU/GPU power.

There will be time in not so distant future (I would guess 1 or 2
years) when we have these 100 dpi CRT displays and 200+ dpi LCD displays.

I’m already using a 21" CRT with resolutions resulting in more than 120 dpi,
so I’m perfectly aware of the problem… heh

The only reasonable solution is to use automatically scaling windows (like
GTK) or to use real world measurement (like mm, cm) instead of pixels. If
that toolkit becomes successful I wouldn’t want such problems with
different resolution displays.

It cannot be avoided entirely, unless you’re going for a vector graphics
solution, using drawing primitives rather than images - which isn’t going to
look very good, unless you’re going to do load time or real time raytracing…

In short; scaling is a last resort, rather than a viable solution. The proper
solution is to allow the GUI designer to provide images in different size.

//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.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 30 May 2001 11:08, Mikko Rantalainen wrote:

David Olofson wrote:

This has been discussed some on the list recently, mostly by me and “Anoq of
the Sun” . Can’t say how hard it would be to
actually implement, but someone will probably try to do it sooner or later.
That is, unless SDL 1.3 will do it, and is in a usable state soon enough. :slight_smile:

also, one last question before i go:

can i resize an [sdl] window without losing its contents? 9ie: how well doe
sdl resond to WM_RESIZE (on win32))?

The approach I’m planning on (you might want to read the thread
with the title “Multiple SDL Windows again” on the newsgroup
for this mailing list)… is to make some kind of integration
with the native platform backend - but I’m only going to do
it for Win32 at first.

And now I have found one more good reason for this approach:

Right now I can’t get access to the HWND of the window
SDL opens on Win32. However, I’m going to need to do
audio with DirectSound (to achieve low-latency) - and
for this I need to set something called the
"coorperative mode" (a nasty Win32 thing)… and for
doing this I need the HWND for the window which
needs the sound focus… So… I need to get
access to that HWND :slight_smile:

I’m just not yet sure how much interaction with the
native backend I’m going to implement… but I’ll
try to design it at least fairly good, so that the
native-support can be extended for things like
controlling window redrawing (which I’m sure I
will also need at some point… :slight_smile:

Cheers–
http://www.HardcoreProcessing.com

Anoq of the Sun wrote

Right now I can’t get access to the HWND of the window
SDL opens on Win32. However, I’m going to need to do
audio with DirectSound (to achieve low-latency) - and
for this I need to set something called the
"coorperative mode" (a nasty Win32 thing)… and for
doing this I need the HWND for the window which
needs the sound focus… So… I need to get
access to that HWND :slight_smile:

I’m just not yet sure how much interaction with the
native backend I’m going to implement… but I’ll
try to design it at least fairly good, so that the
native-support can be extended for things like
controlling window redrawing (which I’m sure I
will also need at some point… :slight_smile:

Sounds to me like it would be better for you to drop SDL and
implement your whole stuff with the native Win32 API’s.

Alex

Alexander Pipelka wrote:

Sounds to me like it would be better for you to drop SDL and
implement your whole stuff with the native Win32 API’s.

I still think the SDL surfaces for framebuffer rendering, and
the blitting operations etc. are very worthwhile to use :slight_smile:
(but I’ve talked about this before on this list :slight_smile:

Cheers–
http://www.HardcoreProcessing.com

i don’t konw the intern of audio, but your little explanation make
me wonder about something.

what if i have a Window, playing music and a comboxbox on it wich
pop-up some result.
the pop-up window is not a child window as it coul go beyond the
windows, so, does a combox stop sound ?

it was just curiosity, but i would be happy if you could answer.

I’m assuming you’re thinking about Win32, as other platforms generally don’t
care about window focus WRT audio.

Either way, I don’t know for sure, but I’d guess it won’t stop audio, as the
popup box would be a “lightweight window” rather than a real window, and it
would be modal to that window, effectively “borrowing” it’s focus instead of
actually taking the focus from the 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.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 30 May 2001 16:36, Lloyd Dupont wrote:

i don’t konw the intern of audio, but your little explanation make
me wonder about something.

what if i have a Window, playing music and a comboxbox on it wich
pop-up some result.
the pop-up window is not a child window as it coul go beyond the
windows, so, does a combox stop sound ?

it was just curiosity, but i would be happy if you could answer.

Right now I can’t get access to the HWND of the window
SDL opens on Win32. However, I’m going to need to do
audio with DirectSound (to achieve low-latency) - and
for this I need to set something called the
"coorperative mode" (a nasty Win32 thing)… and for
doing this I need the HWND for the window which
needs the sound focus… So… I need to get
access to that HWND :slight_smile:

I haven’t been paying attention to this discussion so I apologise in
advance if this isn’t relevant but can’t you use WindowFromPoint-function?
You pass screen coords and it returns HWND. You need to know a point
inside the window, though. Hidden/disabled windows are ignored.

Ismo K?rkk?inen

-------------------|
M.Sc., Assistant | Success covers a multitude of blunders.
Dept. of CS | – George Bernard Shaw
Univ. of Joensuu |
@Ismo_Karkkainen |
Tel:(013)251 7946 |
GSM: 040 774 3722 |On Wed, 30 May 2001, Anoq of the Sun wrote:

Ismo K?rkk?inen wrote:

I haven’t been paying attention to this discussion so I apologise in
advance if this isn’t relevant but can’t you use WindowFromPoint-function?
You pass screen coords and it returns HWND. You need to know a point
inside the window, though. Hidden/disabled windows are ignored.

In the long term, I don’t think this would be the “right” way
of doing it - but it sure sounds useful for testing whether
DirectSound and SDL wants to co-exist! :slight_smile:

Thanks for the hint :slight_smile:

Cheers–
http://www.HardcoreProcessing.com