How to redraw the contents when press and hold the title bar with the mouse？

support
1

Hi there,
I run the Examples of boing project in the GLFW.sln.
I found the contents is blocked ,When i press and hold the title bar with the mouse.Like the picture below.
Then i found the docs written by this:
“On some platforms, a window move, resize or menu operation will cause event processing to block. This is due to how event processing is designed on those platforms. You can use the window refresh callback to redraw the contents of your window when necessary during such operations.”
I know the function [window refresh callback ] will automatically get called when resize window, by use [glfwSetWindowRefreshCallback].

But i still not find how to refresh the contents when hold the title bar.
Sorry for my poor english, i use glfw version:3.2, Visual Stuido 2013.
Does anybody know how to resolve this problem?
Thanks!

Here is the picture,the arrows is where I press and hold:

2

I don’t know the answer off-hand, but here are a few things to try:

  1. Does the refresh callback continue to be called while the title bar is held? A simple test that prints something from within the callback would show this.

  2. If the refresh callback is being called, all you should need to do is re-render the window and swap buffers from within it. In the boing example, I think you just need to copy this code from main into a callback:


       /* Timing */
       t = glfwGetTime();
       dt = t - t_old;
       t_old = t;

       /* Draw one frame */
       display();

       /* Swap buffers */
       glfwSwapBuffers(window);
3

The problem is that the event processing is blocking your thread from running - i.e. glfwPollEvents() does not return until you are no longer dragging the window.

So if you want to continue rendering (or do any other processing) you need to use another thread.

4

Thank you for your help.The refresh callback will not to be called while the title bar is held.
And @dougbinks given the solution, i will try it.

5

thank you for your answer.i’ll try.

6

I wanted to resurrect this somehow old thread). First of all have to say how much I appreciate the work done with GLFW and thanks to @dougbinks for helping the community so much.

Now I know the solution is somehow correct but sadly I wish it was more precise. What needs to run in a separate thread? The render function or the event processing part of the app? I am guessing it’s the render thread (while glfwPollEvents remains in the main thread say). Yet I had a question about this. I am using a fairly complex vulkan pipeline which requires to reset resources all over the place when the window is resized, etc.

So my question is how do typically people do that? Does it mean the solution is to use some kind of of mutex / signal process where the render loop is waiting for the resources to be updated before rendering continues? I would appreciate the feedback from people experienced with that.

Also I saw that thread:

I have to say I don’t understand all of it)) especially I am not sure whether the fiber in question are the C++20 coroutine or something else, but I was wondering where this patch was at? Has it been pushed to the current released version of GLFW?

And secondary question (will third) precisely using the C++20 coroutines has anybody tried to solve this problem (of the render loop blocked when the window is being moved or the mouse pressed on the bottom-right corner -resize- of a window.

Thanks.

7

Hi @Mast4as,

Yes, the render should be run from another thread.

There is also a vulkan query you can use, see:

This uses a native windows fiber, but you don’t have to worry about that since it’s internal to the GLFW code. It’s used to ensure that the glfwPollEvents and other event functions return if more than 1ms has passed inside the function - which can occur when the window is moving/resizing. Your own code does not need to change for this to work.

The PR has not yet been merged. If you move your rendering to another thread you may not require this.