floooh / sokol

minimal cross-platform standalone C headers
https://floooh.github.io/sokol-html5
zlib License
6.74k stars 473 forks source link

sokol_app.h: Resizing window with GLCORE33 on Windows #414

Open dbloodman opened 3 years ago

dbloodman commented 3 years ago

First, thank you for developing sokol libraries.

When resizing the window, context does not scale with window. It is scaled when resizing is finished.

This case works on D3D11.

Example:

Sokol Apps Opengl

floooh commented 3 years ago

Yes, the underlying behaviour is the same as in the D3D11/DXGI backend code (the framebuffer is only resized at the end of the window resizing operation), however DXGI allows to blit the framebuffer with scaling which doesn't look quite as ugly. I haven't found a similar flag for WGL yet (but I haven't looked too hard either).

The "obvious" solution to resize the framebuffer during the window resize unfortunately leads to a video memory spike of up to 500 MBytes which persists for 1 or 2 seconds. I haven't found a solution for yet.

See here:

https://github.com/floooh/sokol/blob/612755ec6665ea71c84aa9ca8a6d2b53f9730293/sokol_app.h#L5747-L5756

Removing the comments there looks "proper" but introduces this memory spike.

kilgariff commented 3 years ago

Just FYI, I don't see the GPU memory spike in the task manager while resizing my app after uncommenting the above code. Test app is based on the ImGui sample from these Zig sokol samples. This is the same behaviour regardless of whether I define SOKOL_D3D11 or SOKOL_GLCORE33.

Windows 10 Pro build 21390 NVIDIA GeForce RTX 2080 Super Driver version 466.47 "Hardware Accelerated GPU Scheduling" feature is enabled

Although the window does resize dynamically, the contents of the window judder as though they're one frame behind.

floooh commented 3 years ago

You won't see the spike in the task manager, because it's only short-lived and I'm also not sure if the task manager actually shows memory used by GPU resources. The realtime memory profiler in Visual Studio shows the spike though.

The "one frame behind" thing is because of some latency sources in the input- and render-pipeline. I think some of those can be slightly improved (such as mouse event latency), but over others the application doesn't have much control unfortunately.

Interestingly I'm now also seeing problems with the rendering during resize and window movements on Win10 and D3D11 with the latest NVIDIA drivers on my machines (with an RTX 2070 and 26x drivers versions, the 25x drivers are fine). When moving or resizing a window, the entire window movement/resizing stutters. Not sure yet what to do about this.