SDL in a Client Window

Walt_Niehoff · December 9, 2008, 7:46pm

Can SDL use an existing client window (Windows) for its rendering target?
With a win32 application, if I have a device context for the client window, I
can create an OpenGL rendering context. In other words, given a client window
handle or device context, I can create a rendering context and render OpenGL
content in the client window. Is there any way I can do the same thing with
SDL?

If there is, please identify the function calls involved and their sequence.

Walt

Mason_Wheeler · December 9, 2008, 9:50pm

There’s a way to do this, but it’s a big, ugly hack and the current way it’s done
won’t work under 1.3 with multiple windows. (And it doesn’t even always work
under SDL 1.2 either.) Better question: Are there plans to implement an
improved version under 1.3? If so, how’s the progress coming on it?>----- Original Message ----

From: Walt Niehoff
Subject: [SDL] SDL in a Client Window

Can SDL use an existing client window (Windows) for its rendering target?
With a win32 application, if I have a device context for the client window, I
can create an OpenGL rendering context. In other words, given a client window
handle or device context, I can create a rendering context and render OpenGL
content in the client window. Is there any way I can do the same thing with
SDL?

If there is, please identify the function calls involved and their sequence.

Walt

Sheshadri_Mantha · December 9, 2008, 11:56pm

The following:
SetEnvironmentVariable(“SDL_WINDOWID”, tWndAddress);

where tWndAddress is the Handle to the client window, expressed as Hex
String (using sprintf with 0x%hx) works in win32, and only in WinDIB.
It has problems with using DirectX.

This is in 1.2x not 1.3.

S-

Walt Niehoff wrote:> Can SDL use an existing client window (Windows) for its rendering target?

With a win32 application, if I have a device context for the client window, I
can create an OpenGL rendering context. In other words, given a client window
handle or device context, I can create a rendering context and render OpenGL
content in the client window. Is there any way I can do the same thing with
SDL?

If there is, please identify the function calls involved and their sequence.

Walt

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

–

** Sheshadri Mantha** | Principal Software Engineer
SeaChange International, Inc.
2655 Campus Drive, Suite 250
San Mateo, CA 94403
www.schange.com http://www.schange.com | @Sheshadri_Mantha
mailto:<a%20href=
Direct: AZ: 520-408-0521; CA: 650-645-4040
Main: 650-645-4000 | Fax: 650-645-4115
Yahoo! IM: babamantha | AIM: sheshmantha
Skype: sheshadrimantha

This e-mail and any attachments may contain information which is
SeaChange International confidential. The information enclosed is
intended only for the addressees herein and may not be copied or
forwarded without permission from SeaChange International.

slouken · December 10, 2008, 8:31am

There’s a way to do this, but it’s a big, ugly hack and the current way it’s done
won’t work under 1.3 with multiple windows. (And it doesn’t even always work
under SDL 1.2 either.) Better question: Are there plans to implement an
improved version under 1.3? If so, how’s the progress coming on it?

Yes, the SDL 1.3 code was designed with the idea in mind that you can pass in
a native window and create an SDL window from it, and create your choice of
renderer and go.

I haven’t actually done it yet though. What are the issues?

See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Mason_Wheeler · December 10, 2008, 2:07pm

Yes, the SDL 1.3 code was designed with the idea in mind that you can pass in
a native window and create an SDL window from it, and create your choice of
renderer and go.

I haven’t actually done it yet though. What are the issues?
I haven’t had any issues with it yet, because I haven’t tried 1.3 yet. But under 1.2,
it’s got a lot of issues. It takes an environment variable, which I think everyone
agrees is an ugly hack, and is prone to failure, especially if you’re not using the
WinDIB driver. (Under Windows. Can’t speak for any other languages.)

Could I make a request for the Windows version? Make sure that you can pass
in a window handle, and not “a window”? A lot of Windows controls have handles
to their drawing surrface, and it would be nice to be able to embed a SDL surface
into a GUI form by passing it the handle of a panel, for example. (The Asphyre
library, which does a lot of the same things as SDL but is specific to Delphi and
Windows, allows you to do this, so I know it can be done.)>----- Original Message ----

From: Sam Lantinga
Subject: Re: [SDL] SDL in a Client Window

Mason_Wheeler · December 10, 2008, 2:16pm

(Under Windows. Can’t speak for any other languages.)
*Platforms. Bleh. Note to self: don’t answer emails when you’ve
just woken up.>----- Original Message ----
From: Mason Wheeler <@Mason_Wheeler>
Subject: Re: [SDL] SDL in a Client Window

Walt_Niehoff · December 10, 2008, 2:19pm

Mason appears to be on top of the basic requirement: pass in a window handle
and get an SDL surface in the window. I think it’s acceptable for SDL to
handle all events in that window, although I won’t claim to have thought this
through.

Walt

Mason_Wheeler · December 10, 2008, 2:31pm

Mason appears to be on top of the basic requirement: pass in a window handle
and get an SDL surface in the window. I think it’s acceptable for SDL to
handle all events in that window, although I won’t claim to have thought this
through.

Walt

Hoo boy. No, you haven’t. This is one of my biggest gripes about SDL 1.2: that
SDL_Video is so tightly coupled with SDL_Event processing. I’d love to see the
two separated. It would be especially bad to have SDL try to handle input if I
embed an SDL surface in a GUI form that I’ve created in Delphi, because Delphi’s
Application object also takes over input handling for any windows you create.

Ideally, SDL_Events should be its own subsystem, completely independent of
SDL_Video. If that’s not possible for some reason, there should at least be a
specific exception for windows that SDL didn’t create itself: If you set it up in an
existing window, assume that that window already has control of event handling
and don’t try to take over. Perhaps provide an API option to allow it to take over
if the programmer decides that would be appropriate in this case?>----- Original Message ----

From: Walt Niehoff
Subject: Re: [SDL] SDL in a Client Window

Walt_Niehoff · December 10, 2008, 2:59pm

Well, I suppose that is a bona fide “issue,” what Sam solicited.

I want to render OpenGL content in a custom control in a parent window. I
think I’m perfectly to have SDL field events for that control since it’s
exclusively a graphics window. However, I do want SDL to let me do the
application-pertinent event processing. I need to do my homework on SDL’s
current event-handling before commenting on the form of hand-off I prefer.

My context is APL2, where I would make external calls on the SDL library. I
would be perfectly happy to handle the message pump myself, but I would try
any facility that SDL documents.

I should add that, in this environment, the Windows process that owns the
parent window is different from the process calling OpenGL functions and
handling events. This works well with XP, but fails with Vista where there is
an apparent problem with OpenGL and DWM.

Walt

Walt_Niehoff · December 10, 2008, 3:13pm

Sheshadri Mantha <sheshadri.mantha schange.com> writes:

The following:
SetEnvironmentVariable(“SDL_WINDOWID”, tWndAddress);

where tWndAddress is the Handle to the client window, expressed as Hex
String (using sprintf with 0x%hx) works in win32, and only in WinDIB.
It has problems with using DirectX.

This is in 1.2x not 1.3.

S-

Forgive me, for I am a newcomer to SDL. What is “1.2x”?

Walt

Brian_Barrett · December 10, 2008, 3:28pm

Hi.

Some unspecified version of SDL 1.2.

SDL 1.3 is quite different, so we need to disguish between which
version we are talking about.

Regards,
Brian.On Wed, Dec 10, 2008 at 3:13 PM, Walt Niehoff wrote:

Forgive me, for I am a newcomer to SDL. What is “1.2x”?

slouken · December 10, 2008, 5:46pm

Hoo boy. No, you haven’t. This is one of my biggest gripes about SDL 1.2: that
SDL_Video is so tightly coupled with SDL_Event processing. I’d love to see the
two separated. It would be especially bad to have SDL try to handle input if I
embed an SDL surface in a GUI form that I’ve created in Delphi, because Delphi’s
Application object also takes over input handling for any windows you create.

FYI, SDL 1.2 doesn’t do any event processing on windows that you create,
and that will be the default for SDL 1.3 as well.

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Mason_Wheeler · December 10, 2008, 5:56pm

FYI, SDL 1.2 doesn’t do any event processing on windows that you create,
and that will be the default for SDL 1.3 as well.

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Good. And will there be an option to hand event processing over to SDL if
you want to? I don’t think I’d ever do that in Delphi, but I can imagine it
being desirable behavior for, say, VC++ apps, under certain conditions.>----- Original Message ----

From: Sam Lantinga
Subject: Re: [SDL] SDL in a Client Window

slouken · December 10, 2008, 6:07pm

Good. And will there be an option to hand event processing over to SDL if
you want to? I don’t think I’d ever do that in Delphi, but I can imagine it
being desirable behavior for, say, VC++ apps, under certain conditions.

Yep. I’m not sure exactly what the API will look like, but we’ll do something
in there. It may be as simple as a general “enable/disable event processing
for this window” API.

See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Mason_Wheeler · December 10, 2008, 6:12pm

Yep. I’m not sure exactly what the API will look like, but we’ll do something
in there. It may be as simple as a general “enable/disable event processing
for this window” API.

Sounds good to me.

void SDL_EnableEventProcessing(SDL_Window *window, bool enabled);

Anyone have any reason why this wouldn’t be a good solution? (I’m just making
up the first argument’s type off the top of my head, of course, but you know
what I mean.)>----- Original Message ----

From: Sam Lantinga
Subject: Re: [SDL] SDL in a Client Window

Jeff_Post · December 10, 2008, 6:55pm

Yep. I’m not sure exactly what the API will look like, but we’ll do
something in there. It may be as simple as a general “enable/disable
event processing for this window” API.

Sounds good to me.

void SDL_EnableEventProcessing(SDL_Window *window, bool enabled);

bool SDL_EnableEventProcessing(SDL_Window *window, bool enabled);
// returns success or failureOn Wed December 10 2008 10:12, Mason Wheeler wrote:

From: Sam Lantinga
Subject: Re: [SDL] SDL in a Client Window

necron · December 11, 2008, 12:00am

For me it just seemed too dificult (early version of SDL) so I opted to make it simply look like a new window inside of my app window. I like the sound of this though. One more reason to be stoked about the next version!

---- Sam Lantinga wrote:=============

There’s a way to do this, but it’s a big, ugly hack and the current way it’s done
won’t work under 1.3 with multiple windows. (And it doesn’t even always work
under SDL 1.2 either.) Better question: Are there plans to implement an
improved version under 1.3? If so, how’s the progress coming on it?

Yes, the SDL 1.3 code was designed with the idea in mind that you can pass in
a native window and create an SDL window from it, and create your choice of
renderer and go.

I haven’t actually done it yet though. What are the issues?

See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

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

Walt_Niehoff · December 13, 2008, 6:23pm

Walt Niehoff <wniehoff stny.rr.com> writes:

Can SDL use an existing client window (Windows) for its rendering target?
With a win32 application, if I have a device context for the client window,
I
can create an OpenGL rendering context. In other words, given a client
window
handle or device context, I can create a rendering context and render OpenGL
content in the client window. Is there any way I can do the same thing with
SDL?

If there is, please identify the function calls involved and their sequence.

Walt

I want to document my experience with this topic in someone else runs into a
similar situation. First, let me describe our peculiar environment: We have a
situation where the application runs in one Win32 process, but the dialog that
serves as the GUI runs in another (inaccessible) process. In this context,
SDL runs in the application process, and we want it to render OpenGL into a
client window owned by the dialog process.

I think the direct advice I’ve gotten in this thread has been sound.
Selecting the windib driver and communicating the client window to SDL via
environmental variables was sound advice. It works under XP with an AMD GPU.
However, under Vista and with an Nvidia 8800 GTX, SetVideoMode failed with a
GetError report of “Unable to reset window for OpenGL context.” Reviewing
source code, I found that message issued in WIN_GL_ResetWindow in
SDL_wingl.c. ResetWindow is called from WIN_GL_SetupWindow in response to a
failure of SetPixelFormat.

Now, let me generalize this problem: We have had exactly that same problem
(SetPixelFormat failure) when we attempt creating our own OpenGL rendering
context via direct calls of Windows functions. It has been demonstrated to
work on systems with AMD GPUs, but it has been demonstrated to fail, as
described above, on systems with three generations with Nvidia GPUs and
Forceware drivers. Before someone suggests updating my driver, let me say
that it is right up to date (Forceware 180.48). I should emphasize that this
particular problem is expressly related to the combination: Nvidia
driver/OpenGL rendering context in a window owned by another process.

This certainly is not an SDL problem.

Donny_Viszneki · December 13, 2008, 8:41pm

Thanks for your exhaustive work Walt, and archiving your efforts on
the mailing list!On Sat, Dec 13, 2008 at 1:23 PM, Walt Niehoff wrote:

Walt Niehoff <wniehoff stny.rr.com> writes:

Can SDL use an existing client window (Windows) for its rendering target?
With a win32 application, if I have a device context for the client window,
I
can create an OpenGL rendering context. In other words, given a client
window
handle or device context, I can create a rendering context and render OpenGL
content in the client window. Is there any way I can do the same thing with
SDL?

If there is, please identify the function calls involved and their sequence.

Walt

I want to document my experience with this topic in someone else runs into a
similar situation. First, let me describe our peculiar environment: We have a
situation where the application runs in one Win32 process, but the dialog that
serves as the GUI runs in another (inaccessible) process. In this context,
SDL runs in the application process, and we want it to render OpenGL into a
client window owned by the dialog process.

I think the direct advice I’ve gotten in this thread has been sound.
Selecting the windib driver and communicating the client window to SDL via
environmental variables was sound advice. It works under XP with an AMD GPU.
However, under Vista and with an Nvidia 8800 GTX, SetVideoMode failed with a
GetError report of “Unable to reset window for OpenGL context.” Reviewing
source code, I found that message issued in WIN_GL_ResetWindow in
SDL_wingl.c. ResetWindow is called from WIN_GL_SetupWindow in response to a
failure of SetPixelFormat.

Now, let me generalize this problem: We have had exactly that same problem
(SetPixelFormat failure) when we attempt creating our own OpenGL rendering
context via direct calls of Windows functions. It has been demonstrated to
work on systems with AMD GPUs, but it has been demonstrated to fail, as
described above, on systems with three generations with Nvidia GPUs and
Forceware drivers. Before someone suggests updating my driver, let me say
that it is right up to date (Forceware 180.48). I should emphasize that this
particular problem is expressly related to the combination: Nvidia
driver/OpenGL rendering context in a window owned by another process.

This certainly is not an SDL problem.

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

–
http://codebad.com/