I've made a project with Qt and OpenGL.
In Qt paintGL() was repeatedly call I beleive, so I was able to change values outside of that function and call update() so that it would paint a new image.
I also believe that it called initializeGL() as soon as you start up the program.
Now my question is:
I want that same functionality in a different program. I do not need to draw any images, etc. I just was wondering if there was a way to make a function like paintGL() that keeps being called so the application never closes. I tried just using a while(true) loop that kept my program running, but the GUI was inactive because of the while loop.
Any tips, other than threading preferably.
Thanks.
The exact mechanism will depend on which GUI toolkit you are using. In general, your app needs to service the run loop constantly for events to be dispatched. That is why your app was unresponsive when you had it running in a while loop.
If you need something repainted constantly, the easiest way is to create a timer when your window is created, and then in the timer even handler or callback, you invalidate your window which forces a repaint. Your paint handler can then be called at the frequency of your timer, such as 25 times per second.
Related
I have a problem handling GLFW poll events. As far as I know, all user input events are handled via callbacks or via constantly checking keyboard / mouse states. The latter is not so efficient an can even result in missing some input (e. g. when button pressed and then released between checking state). What is more, some events like window resizing cannot be handled without callbacks.
So, the problem is that whenever user starts resizing window (presses mouse button but doesn't move mouse), the app seems to freeze. This is, assuming resize callback is enabled and defined validly (even when copied right from GLFW API). And the problem is not that window doesn't redraw. Redraw on callback can be done with creating and calling own render() function in callback function.
The actual problem is that even when I handle resize event properly and redraw on callback, there is still some lag. This lag is after mouse press on decorated window border and when mouse is not moving. Here's a demonstration (button click is highlighted green):
Sorry for messed up GIF. All callbacks listed in GLFW API are enabled and handled (window-, input-, joystick- and monitor-callbacks) and redraw is called in each one. It seems that I'm missing some of the callbacks or GLFW just works like that.
According to this answer, this can't be done without threading:
That only works when the user moves the mouse while holding - just holding left-click on the resize window part still stalls. To fix that, you need to render in a separate thread in addition to this. (No, you can't do that without threading. Sorry, this is how GLFW works, no one except them can change it.)
So, the questions are:
How can I fix this issue without threading? If I can't, I guess I can emulate resizing with different cursors shapes and resizing zones or smth like that...
If this is still impossible to solve in GLFW, do other GLFW alternatives have this issue?
Are there any problems with GLFW similar to this one?
GLFW is not at fault here. It's how the operating system handles certain user input events like mouse down on the decorator resize handles of a window or moving the whole window.
See this answer for a more elaborate detail: Win32: My Application freezes while the user resizes the window
GLFW uses the standard Windows PeekMessage -> TranslateMessage/DispatchMessage loop which you will find in any GUI Windows application. This will get invoked when you call glfwPollEvents() and it processes all Window event messages that the OS has accumulated so far for all windows in this process. After all messages so far have been processed, the call to glfwPollEvents() will return and will allow your own window/game loop to continue.
What happens is that once the user clicks down the window decoration's resize handles, effectively the call to glfwPollEvents() will block within the OS itself in order for the OS / window-manager to intercept the mouse and keyboard messages to do its window resizing/reshaping thing.
I'm afraid that even though Windows will inform the process about the start of a window resize or move action (after which the OS will have control of the window message processing) and GLFW already handling these events internally, right now GLFW will not notify the client application about this. It would be possible though for GLFW to provide an appropriate event callback to the application, so that the application can start a timer or thread only for as long as the window resize/move action happens (as is also mentioned in the linked other Stackoverflow answer).
So, the only thing that you can do in order to keep rendering while the user holds onto the resize handles or while the user moves the window around, is to render in a separate thread.
I'm currently working on a game where I wanted to create a loading screen that basically shows the process of loading all the resources. To do this, I decided to create a separate thread that handles the window. I'm aware that there could be more efficient solutions, but I wanted to create a special mouse cursor and that way was the only way that allowed me to do that without having a buggy mouse when the application is loading a big file.
I read up on the threads on the SFML tutorial page and I learned that I have to do window.setActive(false) in the main thread and then window.setActive(true) in the separate thread in order to have access to the window in the separate thread without getting any problems. This works fine, it doesn't throw any errors and it displays the loading screen very nicely. However, I can't move the window around or interact with it in any way. The mouse cursor is covered by the blue ring from the mouse when it's loading, and I can neither close nor move nor resize the window even though I used sf::Style::Default, so it should be possible.
Can anyone help me out here?
You have it backwards. You blocked the main thread with loading your resources and created a new thread to keep the UI responsive. Not only is that not going to go well in the long term, but in the short term, your operating system still thinks your app is blocked, because the main thread is unresponsive. The OS does not know you created a second thread to keep the user entertained.
You should instead keep the responsive UI on the main thread and create an extra thread for doing the heavy lifting and blocking work. This way you don't have to struggle with your graphics library all the way (and it does not matter whether that's SFML, because they all do this) plus your operating system will not behave as if you blocked your application.
So far, I've only copy/pasted the example that Microsoft has here (but I removed #include ).
I'm trying to figure out how OnPaint is continually called (as to have moving objects), but it doesn't seem to be called more than once.
How do I use the standard Windows C++ graphics library (i.e. GDI+, or another standard Windows API) to create a moving object? Must I call OnPaint myself? Or is there an easy fix to make it continually be called? Or is it just not possible?
The OnPaint() method will only run when Windows thinks that your window needs to be repainted. Which, typically, happens just once when your window is first created. Or when you minimize and restore the window.
To force it to run more than once and animate something, you'll have to tell it that a repaint is required. Best way to do so is by using a timer, it will give you an animation clock. Set the interval to a number that's a bit less than a multiple of 15.625 millseconds. 45 msec is a decent value, it gets you 21 updates per second. Assuming that you can paint fast enough. Call InvalidateRect() in the WM_TIMER message handler. Or Invalidate() if you use Winforms.
I would like to control the main loop in a glut program, I would like to better understand what is the order of execution of the following callbacks:
glutDisplayFunc(drawGLScene);
glutIdleFunc(idle);
glutTimerFunc(TIMER_MS, update, 0);
It's difficult for me to understand how glut queues this calls in a program.
As soon as you want fine control of your event loop, it's time to abandon GLUT. Use SDL, GLFW or do it from scratch. Understanding the inner workings of GLUT will not help you to gain fine control.
You can't. If you want to control the main loop you're going to have to use something like GLFW. Freeglut, a more modern extension of glut might let you do this. The way GLUT works is you specify some callbacks, start the main loop, and then it will call the callbacks whenever appropriate.
It probably calls the timer callback at the beginning of the frame so that you can update your time-since-last-frame value, it probably calls the display callback whenever it needs to render a frame, and it probably calls the idle callback whenever it has to wait before rendering the next frame (maybe in the case that your framerate is limited to exactly 60 fps so if you are rendering frames in less than .017 seconds then it will probably call the idle callback until it is ready to push a frame to the screen).
i just started off using OpenGL and it seems it is not easy to understand the working of the glutMainLoop() what really happens there? Does it stay there doing nothing till any of the function calls responds?
It calls your display callback over and over, calling idle between so that it can maintain a specific framerate if possible, and others if necessary (such as if you resize the window or trigger an input event).
Essentially, within this function is the main program loop, where GLUT does most of the work for you and allows you to simply set up the specific program logic in these callbacks. It's been a while since I've worked with GLUT, and it is certainly confusing at first.
In your display callback should obviously be your main logic to draw whatever it is that should be going on. In the idle callback should be some very lightweight operations to determine what the change in state should be from the last time display was called to the next time. For example, if you're animating something, this would be where you change its position or orientation.
It is exactly as StrixVaria has stated.
glutMainLoop enters the GLUT event processing loop. This routine should be called at most once in a GLUT program. Once called, this routine will never return. It will call as necessary any callbacks that have been registered.
Taken from here
Using opengl and glut together means that you would be writing a 'glut' program that uses opengl commands in the callback functions. main contains glut functions. many glut functions need a callback function to be registered. Those callback functions usually contain opengl commands.
Coming to your question, now when it is clear that you are mainly writing a glut program, it should also be taken that glutMainLoop function call actually executes the callback functions as and when required, which in return executes the opengl commands.
Well glutMainLoop is the main function the keeps calling and calling the displaying functions and which also keeps your window actually opened. You''ll find out that opengl is not that scary.