8000 Check if GLFW has been initialized · Issue #2036 · glfw/glfw · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Check if GLFW has been initialized #2036

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.

Sign up for GitHub

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

Jump to bottom
Open
mlivesu opened this issue Jan 30, 2022 · 11 comments
Open

Check if GLFW has been initialized #2036

mlivesu opened this issue Jan 30, 2022 · 11 comments
Assignees
@elmindreda
Labels
enhancement Feature suggestions and PRs

Comments

@mlivesu
Copy link
mlivesu commented Jan 30, 2022

Hi,
I maintain a library that exposes rendering facilities internally implemented with GLFW. I'd like to handle the calls to glfwInit() and glfwTerminate() directly from within the library, but since there are multiple entry points it would be necessary to know if the environment had already been initialized or not.

I've seen that internally these macros implement similar checks
_GLFW_REQUIRE_INIT()
_GLFW_REQUIRE_INIT_OR_RETURN(NULL)
but they are not accessible from outside GLFW and I could not find an alternative public call in the API.

A similar question was posted long time ago here, but I am not aware of any improvement to this end. Do you think it would be possible to add a boolean function like glfwIsInitialized()? It is true that one could obtain the desired effect by externally storing the GLFW state in an external boolean variable, but in my specific case I'd rather avoid it because the library does not maintain an internal state.

Thanks!
@ws909
Copy link
ws909 commented Jan 30, 2022 •
edited
Loading

The two first lines of glfwInit are these, so there's no need for it.

if (_glfw.initialized)
    return GLFW_TRUE;

Same with glfwTerminate:

GLFWAPI void glfwTerminate(void)
{
    if (!_glfw.initialized)
        return;

    terminate();
}

@mlivesu
Copy link
Author
mlivesu commented Jan 30, 2022

I know I've been there, but this does not solve my problem. glfwInit will return GLFW_TRUE regardless of whether the initialization happened at the current call or at some previous call, therefore from the outside it becomes impossible to distinguish between the two cases.

In my library I have multiple rendering facilities based on GLFW. In this case it is sometimes convenient to perform a test like if (_glfw.initialized), to avoid terminating GLFW meanwhile somebody else is actually using it.

@ws909
Copy link
ws909 commented Jan 30, 2022 •
edited
Loading

If the client is not using GLFW, will your library initialize and terminate GLFW several times during the execution of the program? So each of your rendering functions will begin with glfwInit, and end with glfwTerminate? That sounds like a really bad solution, performance-wise.

@mlivesu
Copy link
Author
mlivesu commented Jan 30, 2022

Yes and no. I have a GL window that is used for online rendering and in 99.9% of the cases is the function that will initialize and terminate GLFW. In addition to this I have an offline rendering facility, based on glfwWindowHint(GLFW_VISIBLE, GLFW_FALSE), that has a very narrow applicability and could be used once in a while either by a windowed application (i.e. meanwhile there is a GL window alive) or in a command line program. For this latter one, I'd need to know whether I should initialize and terminate GLFW or not, and I don't want to have an internal state that tells me so because the library is stateless.

@elmindreda elmindreda self-assigned this Mar 10, 2022
@elmindreda
Copy link
Member

Yup, this or something like it could be useful to have.

@elmindreda elmindreda added the enhancement Feature suggestions and PRs label Mar 10, 2022
@wintertime
Copy link

Hi,

some time ago I needed this for a unittest, but after looking at the GLFW source I found a solution without needing to make a feature request. I wrote this function as a temporary way to check this:

static bool InitializedGlfw() {
  (void)glfwGetKeyScancode(0);
  return glfwGetError(NULL) != GLFW_NOT_INITIALIZED;
}

@wintertime
Copy link

In case of OPs problem, one could argue the problem is that GLFW is broken and should not just maintain a bool to know if it is initialized, but have a reference count and only terminate when the reference count gets to 0. With that change it would work for him automatically without testing and maintaining his own bool.

For another example why the current behaviour is bad: Just imagine a long running program initializing GLFW once at start, using it the whole runtime before and after using a plug-in or library that initializes GLFW only for a moment when needed and terminates it ASAP. The program would then not have an initialized GLFW anymore.

@Frostie314159 Frostie314159 mentioned this issue Mar 30, 2022
Closed
@Frostie314159
Copy link

i made a pull request attempting to fix the issue.

@wintertime wintertime mentioned this issue Apr 2, 2022
Open
@wintertime
Copy link

I added another pull request with the code I wrote for the solution I suggested. If it would be merged, the problem should go away automatically without additional user code for the thread opener and other people with similar scenarios.

@tlf30
Copy link
tlf30 commented Sep 15, 2022

I have run into a use case where I have a plugin that adds GLFW support to an application at runtime, but there are other plugins in the environment that may also add GLFW support. It would be great to check for initialization as to know if I need to terminate it, or if some other piece of code is going to do it (AKA, already initialized it before my code).

I would say for now, I like both implementations #2065 and #2070, and would like to see both merged. Perhaps in the meantime while #2070 is being discussed it would be great to get #2065 merged.

@wintertime
Copy link

@tlf30 On the kanban board under "Projects" you can see there is so many more pressing issues triaged as "Always", "Urgent" and "Now", while this is triaged as a non-pressing "enhancement" waiting for its time in "Todo" without the MRs having been added to the kanban card. I do not expect this to get looked at any soon, although I would classify this issue as a low hanging fruit.

@github-project-automation github-project-automation bot moved this to Quick, Isolated and Approved in Queue Aug 27, 2024
@abhi-k9 abhi-k9 mentioned this issue Feb 12, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@elmindreda elmindreda

Labels
enhancement Feature suggestions and PRs
Projects
Queue
Status: Quick, Isolated and Approved
Milestone
No milestone
Development

No branches or pull requests
6 participants
@elmindreda @wintertime @mlivesu @tlf30 @ws909 @Frostie314159
0