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

**URL:** <https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715>\
**Category:** support\
**Created:** [August 1, 2016, 8:46am UTC](https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715 "2016-08-01T08:46:09Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![djong](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.glfw.org/djong/32/52_2.png) [@djong](https://discourse.glfw.org/u/djong)\
**Post date:** [August 1, 2016, 8:46am UTC](https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715/1 "2016-08-01T08:46:09Z")

</div>

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:  
 ![](https://cdck-file-uploads-canada1.s3.dualstack.ca-central-1.amazonaws.com/flex035/uploads/glfw/original/1X/cbc1da1809bba32ae75552922d29aa018cee67b0.png)

---

<div class="post-metadata">

**Author:** ![tombsar](https://avatars.discourse-cdn.com/v4/letter/t/db5fbb/32.png) [@tombsar](https://discourse.glfw.org/u/tombsar)\
**Post date:** [August 1, 2016, 9:07am UTC](https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715/2 "2016-08-01T09:07:25Z")

</div>

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:

```auto

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

       /* Draw one frame */
       display();

       /* Swap buffers */
       glfwSwapBuffers(window);

```

---

<div class="post-metadata">

**Author:** ![dougbinks](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.glfw.org/dougbinks/32/39_2.png) [@dougbinks](https://discourse.glfw.org/u/dougbinks)\
**Post date:** [August 1, 2016, 9:18am UTC](https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715/3 "2016-08-01T09:18:24Z")

</div>

The problem is that the event processing is blocking your thread from running - i.e. [glfwPollEvents()](http://www.glfw.org/docs/latest/group__window.html#ga37bd57223967b4211d60ca1a0bf3c832) 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.

---

<div class="post-metadata">

**Author:** ![djong](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.glfw.org/djong/32/52_2.png) [@djong](https://discourse.glfw.org/u/djong)\
**Post date:** [August 1, 2016, 9:29am UTC](https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715/4 "2016-08-01T09:29:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![djong](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.glfw.org/djong/32/52_2.png) [@djong](https://discourse.glfw.org/u/djong)\
**Post date:** [August 1, 2016, 9:30am UTC](https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715/5 "2016-08-01T09:30:34Z")

</div>

thank you for your answer.i’ll try.

---

<div class="post-metadata">

**Author:** ![Mast4as](https://avatars.discourse-cdn.com/v4/letter/m/6f9a4e/32.png) [@Mast4as](https://discourse.glfw.org/u/Mast4as)\
**Post date:** [March 23, 2023, 7:03pm UTC](https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715/6 "2023-03-23T19:03:26Z")

</div>

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:

> <https://github.com/glfw/glfw/pull/1426>
>
> This change provides workaround for Windows modal event loop while window is bei…ng resized/moved.
> User can continue using their standard "while" event loop in main thread to do updates in their application.
> 
> Change includes two parts:
> 
> \* Move message dispatching in separate fiber. This allows to "break out" the modal event loop. This is done by using timer which fires after 1msec on window resize/move event. After timer fires, the control returns to main code. There is pretty much no performance overhead for switching fibers in this situation.
> 
> \* Handle non-client left mouse click on title bar. Otherwise Windows does not return in DefWindowProc. Easy way to do this is to defer calling DefWindowProc on WM\_NCLBUTTONDOWN message. Wait until user moves mouse (WMNC\_MOUSEMOVE or WM\_MOUSEMOVE) and then deliver original message. For example, exact same thing is done in \[Google Chromium\](https://chromium.googlesource.com/chromium/src/+/master/ui/views/win/hwnd\_message\_handler.cc#3187) source code.
> 
> This fixes issues like #1231, #561, #185.
> 
> To check how this new behavior works - open any example that does some kind of animation in their main loop. For example, \`particles\`. Then try resizing or dragging window. Notice how all animation stops without this change. But with this pull request the animation will smoothly continue updating.

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.

---

<div class="post-metadata">

**Author:** ![dougbinks](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.glfw.org/dougbinks/32/39_2.png) [@dougbinks](https://discourse.glfw.org/u/dougbinks)\
**Post date:** [March 28, 2023, 11:11am UTC](https://discourse.glfw.org/t/how-to-redraw-the-contents-when-press-and-hold-the-title-bar-with-the-mouse/715/7 "2023-03-28T11:11:13Z")

</div>

Hi @Mast4as,

> [@Mast4as](#):
>
> 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).

Yes, the render should be run from another thread.

> [@Mast4as](#):
>
> 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?

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

> **[Swap chain recreation - Vulkan Tutorial](https://vulkan-tutorial.com/Drawing_a_triangle/Swap_chain_recreation#page_Suboptimal-or-out-of-date-swap-chain)**
>
> A tutorial that teaches you everything it takes to render 3D graphics with the Vulkan API. It covers everything from Windows/Linux setup to rendering and debugging.

> [@Mast4as](#):
>
> Also I saw that thread:
> 
> [https://github.com/glfw/glfw/pull/1426](https://github.com/glfw/glfw/pull/1426)
> 
> 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?

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.