New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating GLFW window objects with existing native handles #25

Open
martinbis11 opened this Issue May 17, 2013 · 41 comments

Comments

Projects
None yet
@martinbis11

martinbis11 commented May 17, 2013

It's really great that we can access native data from the OpenGL context such as glfwGetWin32Window() and glfwGetWGLContext().

It would be nice if that part of the API would be extended to wrap a window that has been created outside of GLFW into GLFW structures for OpenGL context creation, or wrap a context that was created outside of GLFW into GLFW strucutres so that we can use GLFW functions on that context (such as glfwSwapInterval()) for instance.

An example of where this would useful is for screensaver development. Let's say an OpenGL cross-platform screensaver is to be developed. On Windows and Linux for instance, writing a screensaver starts by the OS giving you a window in a platform-specific way. It would be nice to be able to give that OS-specific window handle to GLFW so that from then on, we can use platform-independent GLFW calls to create the context, swap buffers, etc.

@tritao

This comment has been minimized.

Show comment
Hide comment
@tritao

tritao Aug 28, 2013

This would be very useful, I will start implementing this if no one is currently working on it. Any design directions I should have in mind?

tritao commented Aug 28, 2013

This would be very useful, I will start implementing this if no one is currently working on it. Any design directions I should have in mind?

@martinbis11

This comment has been minimized.

Show comment
Hide comment
@martinbis11

martinbis11 Aug 29, 2013

My suggestion would be to avoid creating 2 paths : one to deal with context creation on OS-specific window, and one with the more common API usage. The higher-level / OS-independent API should just call the OS-specific one to avoid duplication and ensure consistent behavior.

martinbis11 commented Aug 29, 2013

My suggestion would be to avoid creating 2 paths : one to deal with context creation on OS-specific window, and one with the more common API usage. The higher-level / OS-independent API should just call the OS-specific one to avoid duplication and ensure consistent behavior.

@hsdk123

This comment has been minimized.

Show comment
Hide comment
@hsdk123

hsdk123 Apr 26, 2014

Hi, this is a feature that seems great to have. Any progress so far?

hsdk123 commented Apr 26, 2014

Hi, this is a feature that seems great to have. Any progress so far?

@kpko

This comment has been minimized.

Show comment
Hide comment
@kpko

kpko May 15, 2014

Hi, this feature would be a great enhancement. How is this prioritized at the moment?

kpko commented May 15, 2014

Hi, this feature would be a great enhancement. How is this prioritized at the moment?

@jsding

This comment has been minimized.

Show comment
Hide comment
@jsding

jsding Oct 3, 2014

+1. This missing feature make GLFW3 useless in many cases(building a editor, etc).

jsding commented Oct 3, 2014

+1. This missing feature make GLFW3 useless in many cases(building a editor, etc).

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Oct 3, 2014

Member

@jsding What UI framework are you using that doesn't already have an OpenGL context widget?

Member

elmindreda commented Oct 3, 2014

@jsding What UI framework are you using that doesn't already have an OpenGL context widget?

@martinbis11

This comment has been minimized.

Show comment
Hide comment
@martinbis11

martinbis11 Oct 3, 2014

I agree this it is usually quite isolated situation when you have to manage your OpenGL context yourself separate from window management, but here is 2 examples where it hit me personally:

We were writing software for interactive-advertisement-like billboards. In this context, we needed to control the creation of the window using low-level OS-specific API. Therefore we had to manage the creation of the OpenGL context ourselves.

Second example is a screensaver that I had to write recently. A little bit of the same: the OS provides you the window and/or you have to create it in a way it can deal with the screensaver. Then if you want to draw OpenGL in this window, you have to create the context yourself.

Hopes this clarifies things a little bit.

martinbis11 commented Oct 3, 2014

I agree this it is usually quite isolated situation when you have to manage your OpenGL context yourself separate from window management, but here is 2 examples where it hit me personally:

We were writing software for interactive-advertisement-like billboards. In this context, we needed to control the creation of the window using low-level OS-specific API. Therefore we had to manage the creation of the OpenGL context ourselves.

Second example is a screensaver that I had to write recently. A little bit of the same: the OS provides you the window and/or you have to create it in a way it can deal with the screensaver. Then if you want to draw OpenGL in this window, you have to create the context yourself.

Hopes this clarifies things a little bit.

@hsdk123

This comment has been minimized.

Show comment
Hide comment
@hsdk123

hsdk123 Oct 3, 2014

I have a similar need. I'm needing to create a c# editor with an opengl window, but in order to do that, the opengl window must be created upon a win32 child window (hence using it's handle).

hsdk123 commented Oct 3, 2014

I have a similar need. I'm needing to create a c# editor with an opengl window, but in order to do that, the opengl window must be created upon a win32 child window (hence using it's handle).

@httpdigest

This comment has been minimized.

Show comment
Hide comment
@httpdigest

httpdigest Nov 4, 2014

This would be a truly awesome feature to have for GLFW! Currently I am using GLFW through LWJGL 3 and it works very well. Except for the fact that I need to embed the window/component into a Java SWT application as an SWT Canvas. Now, you might say "well, just use the SWT-provided GLCanvas", and you would be right, except for the fact that it does not (as of the current development version 4.5) support creation of GL >= 3.0 core contexts. And its Mac OS X implementation is hugely outdated and gives a deprecated warning everytime it is run on Mac.

LWJGL 3 chose GLFW for good reasons and having to decouple window management from GL context management would be a HUGE win for both sides, in my honest opinion.

httpdigest commented Nov 4, 2014

This would be a truly awesome feature to have for GLFW! Currently I am using GLFW through LWJGL 3 and it works very well. Except for the fact that I need to embed the window/component into a Java SWT application as an SWT Canvas. Now, you might say "well, just use the SWT-provided GLCanvas", and you would be right, except for the fact that it does not (as of the current development version 4.5) support creation of GL >= 3.0 core contexts. And its Mac OS X implementation is hugely outdated and gives a deprecated warning everytime it is run on Mac.

LWJGL 3 chose GLFW for good reasons and having to decouple window management from GL context management would be a HUGE win for both sides, in my honest opinion.

@elmindreda elmindreda added the Wayland label Nov 4, 2014

@elmindreda elmindreda self-assigned this Nov 4, 2014

@swtsvn

This comment has been minimized.

Show comment
Hide comment
@swtsvn

swtsvn Nov 19, 2014

Hi.
Currently I am working on a project where this is going to be useful. I see that this bug was opened in 2013, and is still in open status. Can anyone give information on whether this has been implemented yet ?
Greatly appreciate your time.
Thanks

swtsvn commented Nov 19, 2014

Hi.
Currently I am working on a project where this is going to be useful. I see that this bug was opened in 2013, and is still in open status. Can anyone give information on whether this has been implemented yet ?
Greatly appreciate your time.
Thanks

@elmindreda elmindreda added the Mir label Nov 19, 2014

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Nov 19, 2014

Member

@swtsvn It has not.

Member

elmindreda commented Nov 19, 2014

@swtsvn It has not.

@printerhkj

This comment has been minimized.

Show comment
Hide comment
@printerhkj

printerhkj Dec 9, 2014

I have a similar need too, i need create a opengl window as a child window of a mfc window.

printerhkj commented Dec 9, 2014

I have a similar need too, i need create a opengl window as a child window of a mfc window.

@majkcramer

This comment has been minimized.

Show comment
Hide comment
@majkcramer

majkcramer Dec 19, 2014

I have a similar need too.

majkcramer commented Dec 19, 2014

I have a similar need too.

@paperManu

This comment has been minimized.

Show comment
Hide comment
@paperManu

paperManu Dec 19, 2014

Could this make GLFW able to handle windows created in different displays on X11 ? This would be especially useful to create GL applications using multiple GPUs.

paperManu commented Dec 19, 2014

Could this make GLFW able to handle windows created in different displays on X11 ? This would be especially useful to create GL applications using multiple GPUs.

@TronicLabs

This comment has been minimized.

Show comment
Hide comment
@TronicLabs

TronicLabs Feb 4, 2015

+1 for window created upon a child window using it's handle

TronicLabs commented Feb 4, 2015

+1 for window created upon a child window using it's handle

@ultrant

This comment has been minimized.

Show comment
Hide comment
@ultrant

ultrant Mar 8, 2015

+1 for window created upon a child window using it's handle

ultrant commented Mar 8, 2015

+1 for window created upon a child window using it's handle

@galek

This comment has been minimized.

Show comment
Hide comment
@galek

galek commented Nov 9, 2015

+1

@elmindreda elmindreda modified the milestones: 3.2, 3.3 Feb 16, 2016

@WRodewald

This comment has been minimized.

Show comment
Hide comment
@WRodewald

WRodewald commented Mar 26, 2016

+1

@hsdk123

This comment has been minimized.

Show comment
Hide comment
@hsdk123

hsdk123 Mar 26, 2016

It's difficult to believe that this feature has been put off for 3 years - it would be great for this to be incorporated.

hsdk123 commented Mar 26, 2016

It's difficult to believe that this feature has been put off for 3 years - it would be great for this to be incorporated.

elmindreda added a commit that referenced this issue Mar 29, 2016

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jul 31, 2016

Member

Sorry it's taken so long. It's been difficult to schedule this partly because a lot of internals needed restructuring. That work is done now.

Member

elmindreda commented Jul 31, 2016

Sorry it's taken so long. It's been difficult to schedule this partly because a lot of internals needed restructuring. That work is done now.

@hsdk123

This comment has been minimized.

Show comment
Hide comment
@hsdk123

hsdk123 Aug 1, 2016

@elmindreda Woah, that sounds great! Does this mean we'll see progress on this now? (been waiting for this for 2+ years now)

hsdk123 commented Aug 1, 2016

@elmindreda Woah, that sounds great! Does this mean we'll see progress on this now? (been waiting for this for 2+ years now)

@starseeker

This comment has been minimized.

Show comment
Hide comment
@starseeker

starseeker Aug 6, 2016

Would the API for this look something like:

GLFWAPI GLFWwindow* glfwWrapWindowWin32(HWND *win, HGLRC *context, GLFWwindow *share);

in glfw3native.h? (With, obviously, appropriate functions for other backends)

There seem to be three possible scenarios:

  1. given context without window, create and provide a wrapping GLFWwindow
  2. given a window without an OpenGL context, initialize the context and create the GLFWwindow using the existing OS info (my case - have Tk window, need OpenGL context + cross platform OpenGL management of it.)
  3. given a window and context from the OS (i.e. a fully created, working OpenGL window from another toolkit or something like OGRE or OSG) populate the GLFWwindow structure with the necessary information to allow GLFW wrapper functions to manipulate it. (I may have use for this case down the road...)

With the above API, if both are NULL there is nothing returned (that's the case where you want the main glfw API, and there isn't enough information to do the job here.)
If the win is NULL and context isn't, it's case # 1
If win is not NULL and context is, it's case # 2
if both are non-NULL, it's case # 3

Does case # 1 even make sense? Or perhaps, does it only make sense on some platforms?

starseeker commented Aug 6, 2016

Would the API for this look something like:

GLFWAPI GLFWwindow* glfwWrapWindowWin32(HWND *win, HGLRC *context, GLFWwindow *share);

in glfw3native.h? (With, obviously, appropriate functions for other backends)

There seem to be three possible scenarios:

  1. given context without window, create and provide a wrapping GLFWwindow
  2. given a window without an OpenGL context, initialize the context and create the GLFWwindow using the existing OS info (my case - have Tk window, need OpenGL context + cross platform OpenGL management of it.)
  3. given a window and context from the OS (i.e. a fully created, working OpenGL window from another toolkit or something like OGRE or OSG) populate the GLFWwindow structure with the necessary information to allow GLFW wrapper functions to manipulate it. (I may have use for this case down the road...)

With the above API, if both are NULL there is nothing returned (that's the case where you want the main glfw API, and there isn't enough information to do the job here.)
If the win is NULL and context isn't, it's case # 1
If win is not NULL and context is, it's case # 2
if both are non-NULL, it's case # 3

Does case # 1 even make sense? Or perhaps, does it only make sense on some platforms?

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Aug 7, 2016

Member

(Please don't write #1, etc. as that creates cross-links to unrelated issues.)

Would the API for this look something like [...] in glfw3native.h? (With, obviously, appropriate functions for other backends)

@starseeker Yes, very much like that, and thank you for summarizing the different cases!

I can't think of a practical example of case 1, especially not one common enough to support. Do any of you need this one?

I can see uses for case 2, when you are handed a top-level window and want to manage it with GLFW and render to it. Context creation will be somewhat constrained, because the framebuffer format is dictated by the pixel format (on Windows, if set) or visual (on X11, always) of the window, but otherwise it should work fine. This is the one I know SDL2 supports and I've been aligning some internals to ensure we do it in the same way.

However, those of you wanting to manage child windows may be better served by a standalone context creation only library. If that's what you need then I'd rather write that than further complicate the internals of GLFW. On non-callback based systems like X11 I don't see how this would work at all, as either the main UI toolkit or GLFW would pull events from the queue and simply discard undesirable ones.

As for case 3, why would you need GLFW if you are using OGRE or OSG? They already provide window and context management in their own consistent style. It's not a difficult case to support, but what software hands you a window and context without the tools to manage them, to the point of leaving them alone so it won't interfere with GLFW?

Member

elmindreda commented Aug 7, 2016

(Please don't write #1, etc. as that creates cross-links to unrelated issues.)

Would the API for this look something like [...] in glfw3native.h? (With, obviously, appropriate functions for other backends)

@starseeker Yes, very much like that, and thank you for summarizing the different cases!

I can't think of a practical example of case 1, especially not one common enough to support. Do any of you need this one?

I can see uses for case 2, when you are handed a top-level window and want to manage it with GLFW and render to it. Context creation will be somewhat constrained, because the framebuffer format is dictated by the pixel format (on Windows, if set) or visual (on X11, always) of the window, but otherwise it should work fine. This is the one I know SDL2 supports and I've been aligning some internals to ensure we do it in the same way.

However, those of you wanting to manage child windows may be better served by a standalone context creation only library. If that's what you need then I'd rather write that than further complicate the internals of GLFW. On non-callback based systems like X11 I don't see how this would work at all, as either the main UI toolkit or GLFW would pull events from the queue and simply discard undesirable ones.

As for case 3, why would you need GLFW if you are using OGRE or OSG? They already provide window and context management in their own consistent style. It's not a difficult case to support, but what software hands you a window and context without the tools to manage them, to the point of leaving them alone so it won't interfere with GLFW?

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Aug 7, 2016

Member

To clarify; none of this is a roundabout way of saying no.

Member

elmindreda commented Aug 7, 2016

To clarify; none of this is a roundabout way of saying no.

@starseeker

This comment has been minimized.

Show comment
Hide comment
@starseeker

starseeker Aug 8, 2016

Would the distinction between a context-only library and the SDL2-like scenario be that in the former the parent toolkit would assume full responsibility for event and key binding handling, where in the latter the events from the parent toolkit would be for GLFW to handle? The latter has some appeal to me if it would let me define a set of bindings once and re-use them in multiple different application frameworks (or am I ms-interpreting what's possible there? I guess I might need to translate the parent events into GLFW events for the embedded window...)

I'll go ahead and lay out the concrete case that is driving my own interest in issue 25, since it may help to determine if what I'm thinking is sensible... apologies if this is too specific/too much detail, but I'm not too sure of some of my terminology so perhaps the concrete example will help...

BRL-CAD has a "display manager" layer which has the responsibility (among other things) to provide a drawing canvas on which our geometry is visualized. We have a number of back-ends for this library, each platform specific. For example, our glx backend code responsible for creating a context is here:

https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/libdm/dm-ogl.c#l635

Right now, those backends are a mix of Tk code used for window handling if a context isn't already provided, and glx/opengl calls manipulating the context. We have multiple OpenGL backends for specific platforms - what I would like to do instead is replace these with one GLFW cross platform backend that removes the need both for Tk and for platform specific OpenGL management. For situations where libdm needs to provide both window and context, GLFW as it stands seems like an excellent fit. The trick is what to do when:

a) the context already exists (say, created by an application with JOGL or ruby-opengl or Qt's OpenGL widget) and the display manager needs to do its drawing and management using that already existing context (several of our client programs either do this now or plan to)

b) an existing application has a window into which the libdm context needs to go but can't create its own context (currently the scenario for all of BRL-CAD's primary Tk-based graphical applications.)

Ideally, I would like libdm to use one backend to handle all of these cases without having to have the Tk and platform specific glx/wgl/etc. calls in the libdm logic we currently need. One of our devs was able to start working on this by using the lower level OpenSceneGraph layers to get an OpenGL context:

https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/libdm/dm-osgl.cpp#l599

but OSG is a very heavy dependency to have when we're not actually using its scene graph features. Hence my interest in GLFW as a possible "simple and focused" solution to the portable OpenGL problem.

Since I can see a use for both the "window managing" GLFW when libdm is told to create and manage its own window and the "embed and/or manipulate the context" scenario for the other cases, I was hopeful that the latter might be practical as a "lower level" API in GLFW and allow for a single library solution. However, complicating GLFW's API unnecessarily would definitely be a Bad Thing, so I'd be open to a separate solution as well.

Not sure how all of that compares to the use cases of others interested in this particular issue...

starseeker commented Aug 8, 2016

Would the distinction between a context-only library and the SDL2-like scenario be that in the former the parent toolkit would assume full responsibility for event and key binding handling, where in the latter the events from the parent toolkit would be for GLFW to handle? The latter has some appeal to me if it would let me define a set of bindings once and re-use them in multiple different application frameworks (or am I ms-interpreting what's possible there? I guess I might need to translate the parent events into GLFW events for the embedded window...)

I'll go ahead and lay out the concrete case that is driving my own interest in issue 25, since it may help to determine if what I'm thinking is sensible... apologies if this is too specific/too much detail, but I'm not too sure of some of my terminology so perhaps the concrete example will help...

BRL-CAD has a "display manager" layer which has the responsibility (among other things) to provide a drawing canvas on which our geometry is visualized. We have a number of back-ends for this library, each platform specific. For example, our glx backend code responsible for creating a context is here:

https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/libdm/dm-ogl.c#l635

Right now, those backends are a mix of Tk code used for window handling if a context isn't already provided, and glx/opengl calls manipulating the context. We have multiple OpenGL backends for specific platforms - what I would like to do instead is replace these with one GLFW cross platform backend that removes the need both for Tk and for platform specific OpenGL management. For situations where libdm needs to provide both window and context, GLFW as it stands seems like an excellent fit. The trick is what to do when:

a) the context already exists (say, created by an application with JOGL or ruby-opengl or Qt's OpenGL widget) and the display manager needs to do its drawing and management using that already existing context (several of our client programs either do this now or plan to)

b) an existing application has a window into which the libdm context needs to go but can't create its own context (currently the scenario for all of BRL-CAD's primary Tk-based graphical applications.)

Ideally, I would like libdm to use one backend to handle all of these cases without having to have the Tk and platform specific glx/wgl/etc. calls in the libdm logic we currently need. One of our devs was able to start working on this by using the lower level OpenSceneGraph layers to get an OpenGL context:

https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/trunk/src/libdm/dm-osgl.cpp#l599

but OSG is a very heavy dependency to have when we're not actually using its scene graph features. Hence my interest in GLFW as a possible "simple and focused" solution to the portable OpenGL problem.

Since I can see a use for both the "window managing" GLFW when libdm is told to create and manage its own window and the "embed and/or manipulate the context" scenario for the other cases, I was hopeful that the latter might be practical as a "lower level" API in GLFW and allow for a single library solution. However, complicating GLFW's API unnecessarily would definitely be a Bad Thing, so I'd be open to a separate solution as well.

Not sure how all of that compares to the use cases of others interested in this particular issue...

@TronicLabs

This comment has been minimized.

Show comment
Hide comment
@TronicLabs

TronicLabs Aug 8, 2016

my current implementation for simple attach to parent handle the GLFW windows as child...
for other OS need to investigate...

GLFWAPI HWND glfwSetWin32WindowParent(HWND parentHandle)
{
    _GLFW_REQUIRE_INIT_OR_RETURN(NULL);
    glfwWindowHint(GLFW_CHILD, GLFW_TRUE);
    return win32Parent.parentHWND = parentHandle;
}
...
window->win32.handle = CreateWindowExW(exStyle,
                                           _GLFW_WNDCLASSNAME,
                                           wideTitle,
                                           style,
                                           xpos, ypos,
                                           fullWidth, fullHeight,
                                           wndconfig->child ? win32Parent.parentHWND : NULL,
                                           NULL, // No window menu
                                           GetModuleHandleW(NULL), 
                                           NULL)

TronicLabs commented Aug 8, 2016

my current implementation for simple attach to parent handle the GLFW windows as child...
for other OS need to investigate...

GLFWAPI HWND glfwSetWin32WindowParent(HWND parentHandle)
{
    _GLFW_REQUIRE_INIT_OR_RETURN(NULL);
    glfwWindowHint(GLFW_CHILD, GLFW_TRUE);
    return win32Parent.parentHWND = parentHandle;
}
...
window->win32.handle = CreateWindowExW(exStyle,
                                           _GLFW_WNDCLASSNAME,
                                           wideTitle,
                                           style,
                                           xpos, ypos,
                                           fullWidth, fullHeight,
                                           wndconfig->child ? win32Parent.parentHWND : NULL,
                                           NULL, // No window menu
                                           GetModuleHandleW(NULL), 
                                           NULL)
@evilWicked

This comment has been minimized.

Show comment
Hide comment
@evilWicked

evilWicked Aug 12, 2016

As another use case I am developing a VST audio plugin which needs a gui.

These things come as a DLL where you are handed a HWND handle on windows and some variation on mac https://github.com/josephernest/smplr/blob/master/vst/pluginterfaces/gui/iplugview.h . The model is that the plugin creates a window - while resize events, keyboard and mouse wheel events get passed to the plugin via the iplugview interface

At present I am using GLFW as a dev tool to create a context while I build a scene graph and sprite batcher with the intent of writing a native GL context creator using http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/ after I have proven that everything else works (which I am looking forward to like a trip to the dentist)

But if I could simply use GLFW then that would be really nice.

evilWicked commented Aug 12, 2016

As another use case I am developing a VST audio plugin which needs a gui.

These things come as a DLL where you are handed a HWND handle on windows and some variation on mac https://github.com/josephernest/smplr/blob/master/vst/pluginterfaces/gui/iplugview.h . The model is that the plugin creates a window - while resize events, keyboard and mouse wheel events get passed to the plugin via the iplugview interface

At present I am using GLFW as a dev tool to create a context while I build a scene graph and sprite batcher with the intent of writing a native GL context creator using http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/ after I have proven that everything else works (which I am looking forward to like a trip to the dentist)

But if I could simply use GLFW then that would be really nice.

@TronicLabs

This comment has been minimized.

Show comment
Hide comment
@TronicLabs

TronicLabs Aug 13, 2016

@evilWicked
yeah, this is really my current usage scenario,
but GLFW must be consistent across all platforms it supports.
Now, I'm testing on Windows OS DLLs, with mine simply parent handle attach mod,
and seems to work very well, using his 'draw while loop' in an separate thread.

TronicLabs commented Aug 13, 2016

@evilWicked
yeah, this is really my current usage scenario,
but GLFW must be consistent across all platforms it supports.
Now, I'm testing on Windows OS DLLs, with mine simply parent handle attach mod,
and seems to work very well, using his 'draw while loop' in an separate thread.

@tylorr

This comment has been minimized.

Show comment
Hide comment
@tylorr

tylorr Oct 2, 2016

@TronicLabs I'm going to try to implement your solution for Windows because that is all I need right now, quick question though, what is win32Parent and where does it live?

tylorr commented Oct 2, 2016

@TronicLabs I'm going to try to implement your solution for Windows because that is all I need right now, quick question though, what is win32Parent and where does it live?

@TronicLabs

This comment has been minimized.

Show comment
Hide comment
@TronicLabs

TronicLabs Oct 5, 2016

@tylorr
It's part of my implementation, you can not find it anywhere.
I have not posted all of the code to avoid confusion because it changes some things in the library globally.
So we hope that it will be soon implemented natively.

TronicLabs commented Oct 5, 2016

@tylorr
It's part of my implementation, you can not find it anywhere.
I have not posted all of the code to avoid confusion because it changes some things in the library globally.
So we hope that it will be soon implemented natively.

@zamaudio

This comment has been minimized.

Show comment
Hide comment
@zamaudio

zamaudio Dec 3, 2016

IMHO, I don't think this should be part of the "native access" part of GLFW. It ought to be a standard thing you might do by creating a window. For example, you might have a new API call called GLFWwindow* glfwCreateWindowEmbed ( int width, int height, const char *title, GLFWmonitor *monitor, GLFWwindow* embed, void* parent, enum nativetype type) that takes an additional pair of parameters, the pointer to the native parent window, so that the GLFWwindow embed structure is populated internally with the parent window as the native parent. The nativetype enum should reflect the type of the parent window in such a way that you dont need to expose anything extra from the native access part of glfw, you just want glfw to be able to interpret the native pointer correctly. Anyway this is just a suggestion.

zamaudio commented Dec 3, 2016

IMHO, I don't think this should be part of the "native access" part of GLFW. It ought to be a standard thing you might do by creating a window. For example, you might have a new API call called GLFWwindow* glfwCreateWindowEmbed ( int width, int height, const char *title, GLFWmonitor *monitor, GLFWwindow* embed, void* parent, enum nativetype type) that takes an additional pair of parameters, the pointer to the native parent window, so that the GLFWwindow embed structure is populated internally with the parent window as the native parent. The nativetype enum should reflect the type of the parent window in such a way that you dont need to expose anything extra from the native access part of glfw, you just want glfw to be able to interpret the native pointer correctly. Anyway this is just a suggestion.

@zamaudio

This comment has been minimized.

Show comment
Hide comment
@zamaudio

zamaudio Dec 3, 2016

Most of the time, you probably already have an enum for doing platform specific code within your application, alternatively you might define separate API calls and do the #ifdef yourself... but then it would probably need to go into native access ?

zamaudio commented Dec 3, 2016

Most of the time, you probably already have an enum for doing platform specific code within your application, alternatively you might define separate API calls and do the #ifdef yourself... but then it would probably need to go into native access ?

@drobilla

This comment has been minimized.

Show comment
Hide comment
@drobilla

drobilla Feb 13, 2017

I've created a (currently less than half baked) fork to tinker with this at https://github.com/drobilla/glfw if anyone's interested.

In the past, I and others have had many subtle (or not so subtle) problems with reparenting, so the approach here is to set a (pointer) hint to the native parent window's handle before creating the GLFW window (allowing it to be created with the correct parent). Unfortunate that a new hint function is needed for this since ints won't do, but the same extensibility rationale applies, and presumably more useful cases for setting pointer hints will show up. Alternatively, we could just add a function specifically to set the parent before creating the window (I don't care, it just seemed more future proof this way).

When I get some more time I'll try to figure out what's going on with Gtk, and take a stab at Windows and OSX. This general approach is known to work well on all three platforms, but GLFW is doing something differently that I haven't tracked down yet. I have no idea about Wayland.

drobilla commented Feb 13, 2017

I've created a (currently less than half baked) fork to tinker with this at https://github.com/drobilla/glfw if anyone's interested.

In the past, I and others have had many subtle (or not so subtle) problems with reparenting, so the approach here is to set a (pointer) hint to the native parent window's handle before creating the GLFW window (allowing it to be created with the correct parent). Unfortunate that a new hint function is needed for this since ints won't do, but the same extensibility rationale applies, and presumably more useful cases for setting pointer hints will show up. Alternatively, we could just add a function specifically to set the parent before creating the window (I don't care, it just seemed more future proof this way).

When I get some more time I'll try to figure out what's going on with Gtk, and take a stab at Windows and OSX. This general approach is known to work well on all three platforms, but GLFW is doing something differently that I haven't tracked down yet. I have no idea about Wayland.

@timscaffidi

This comment has been minimized.

Show comment
Hide comment
@timscaffidi

timscaffidi Jun 16, 2017

I'm working on a project where this feature is needed. Specifically I need to be able to create multiple contexts which all share with an external native context. Are there any existing cross-platform libraries that allow this? We were hoping glfw handled it but it looks like this issue is dead in the water.

@drobilla We may end up going down the same route as you. Have you had any time to look into Windows support yet?

timscaffidi commented Jun 16, 2017

I'm working on a project where this feature is needed. Specifically I need to be able to create multiple contexts which all share with an external native context. Are there any existing cross-platform libraries that allow this? We were hoping glfw handled it but it looks like this issue is dead in the water.

@drobilla We may end up going down the same route as you. Have you had any time to look into Windows support yet?

@drobilla

This comment has been minimized.

Show comment
Hide comment
@drobilla

drobilla Jun 17, 2017

@timscaffidi There is this PR on my fork: drobilla#1 though the semantics of how it embeds are different (and IMO shouldn't be, see comments). I haven't personally tried this on Windows yet.

In the LV2 universe we made Pugl for this problem, several projects use it for embeddable plugin GUIs. It's minimal and much less fully featured than GLFW (you might need to tinker for specific needs), but embedding works fine on all three platforms (embedding and no static data whatsoever are its reason d'être): https://github.com/drobilla/pugl

drobilla commented Jun 17, 2017

@timscaffidi There is this PR on my fork: drobilla#1 though the semantics of how it embeds are different (and IMO shouldn't be, see comments). I haven't personally tried this on Windows yet.

In the LV2 universe we made Pugl for this problem, several projects use it for embeddable plugin GUIs. It's minimal and much less fully featured than GLFW (you might need to tinker for specific needs), but embedding works fine on all three platforms (embedding and no static data whatsoever are its reason d'être): https://github.com/drobilla/pugl

@phoenixx2

This comment has been minimized.

Show comment
Hide comment
@phoenixx2

phoenixx2 Nov 27, 2017

Would also love to see this implemented. My use case is a general API, where you're able to place OpenGL canvas child windows on any window, and set any of them to become fullscreen. I like that GLFW has everything setup to handle fullscreen extremely well (including multi-monitor, DPI issues, sampling), while at the same time I'd rather not have to use another library, a "context creation only library" as you would call it, to handle the child window case.

phoenixx2 commented Nov 27, 2017

Would also love to see this implemented. My use case is a general API, where you're able to place OpenGL canvas child windows on any window, and set any of them to become fullscreen. I like that GLFW has everything setup to handle fullscreen extremely well (including multi-monitor, DPI issues, sampling), while at the same time I'd rather not have to use another library, a "context creation only library" as you would call it, to handle the child window case.

@elmindreda elmindreda modified the milestones: 3.3, 3.4 Dec 7, 2017

@BrotherMaestro

This comment has been minimized.

Show comment
Hide comment
@BrotherMaestro

BrotherMaestro Dec 18, 2017

+1. I'm trying to instantiate a OpenGL context within an existing Window Visualization that has been created by an external program (CODESYS V3).
Hows this feature coming along? Any progress to report?

BrotherMaestro commented Dec 18, 2017

+1. I'm trying to instantiate a OpenGL context within an existing Window Visualization that has been created by an external program (CODESYS V3).
Hows this feature coming along? Any progress to report?

elmindreda added a commit that referenced this issue Jan 9, 2018

@feliwir

This comment has been minimized.

Show comment
Hide comment
@feliwir

feliwir Jan 16, 2018

Any updates from this?

feliwir commented Jan 16, 2018

Any updates from this?

elmindreda added a commit that referenced this issue Jan 17, 2018

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Jan 17, 2018

Member

See the attach-win32-window branch for a first draft of the Windows implementation of this feature.

Member

elmindreda commented Jan 17, 2018

See the attach-win32-window branch for a first draft of the Windows implementation of this feature.

@TronicLabs

This comment has been minimized.

Show comment
Hide comment
@TronicLabs

TronicLabs Feb 11, 2018

if we can have other platform draft implementation, we can finalize and test this feature.

TronicLabs commented Feb 11, 2018

if we can have other platform draft implementation, we can finalize and test this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment