LWJGL3: Request rendering on resize rather then directly resizing

[WickedShell]

I've been having a problem when resizing windows with LWJGL3 under both Windows and Linux that while dragging the window around triggers a lot of resize events. That's fine by itself however this can (and does) form a very tight loop which prevents runnables from being run. If you're rendering thread posts a runnable for any reason this will just be queued, which can lead to a very large set of runnables pending which can then take a surprising amount of time to clear. It leads to a weird problem where the window is relatively current, but once you stop resizing it it freezes.

I'm not fully sold on this being the correct fix. In my case the behavior that lead to this was an intermediate state and the current behavior that can post all the runnables will be changing either way. The patch as PR'd resolves the problem for me, but I'm not fully sure that this is really the correct fix (and possibly has a more significant impact on projects other then my own).

Anyways thought I'd throw it up since I'd investigated it,and it fixes it for me. If it's out of scope I'm not fussed if it's closed :)

[Tom-Ski]

If you don't move the mouse but are still "resizing" the window, we shouldnt get this update and you will have the same problem right? What is actually causing the blocking behavior?

[WickedShell]

I had 2 different projects that were suffering from this, I've worked around one of them, and the other I just need to come back to fix it. The problem is that when drawing a component an asset would be missing, and due to the load time it's thrown to a worker pool to be loaded. The worker pool on completion would post a runnable. However while a user is just resizing the window trying to fit something this can lead to a lot of runnables being posted. The block results from the processing time of the runnables. From here we start to get into implementation details, but the short form is that depending on how they resized the window assets were removed from the currently in use asset list, and then could be readded if they expanded again, even though the original runnable is still pending.

The other problem with this is if you stop resizing the window and don't do anything the runnables will never be run. And if a user doesn't know to move the mouse inside the application this results in stale data being shown. This is most insidious as normally the act of posting a runnable is sufficient to retrigger rendering.

The first problem I listed can be worked around in application code (as I've done), and it's not unreasonable to say it was simply bad design, but the second problem would apply to all projects, and I don't see how to work around that in application code except to know that on a resize event you need to manually request rendering again, which is a trap for most people.

If you don't move the mouse but are still "resizing" the window, we shouldnt get this update and you will have the same problem right?

I'm not quite following you. If you move the mouse to resize the window there is still a interval before the mouse moves again in which the system can fully render everything.

[tommyettinger]

This is a really concise PR; has anyone tested it recently? It seems like the cases where this helps, it helps a lot, but it needs a specific type of application, with Runnables used heavily, to matter. I'm not especially clear on the internals of LWJGL3 rendering in libGDX, but it looks like this just removes a forced render() and replaces it with a request to render when possible. That seems like a better way, so I'm approving.

[crykn]

I'm not sure, whether this is the right way of fixing this problem. @cypherdare suggested a different method in #6272, which should also take care of the user "resizing", but not moving their mouse.

And if I understand #4419 correctly, by (properly) separating the main loop we would also prevent the issue from ever occurring.