Possible deadlock in monitor layer

[TonyBarbour]

Because the LUNARG_monitor layer calls SetWindowText at present time, it will block until the thread processing window events processes the message. If that thread is blocked waiting for present to finish, there is deadlock.

A possible solution would be to avoid the call to SetWindowText and render the FPS measurement directly into the present buffer (see the overlay sample in VulkanSamples). The problem was that rendering the FPS using the method in the overlay sample affected the FPS seen by high frame rate Vulkan apps. Finding a low overhead means of rendering the FPS into the present buffer or an overlay buffer would be one way to avoid the possible deadlock.

[martty]

I encountered this deadlock today, is there no alternative way to change the window title that is not susceptible to deadlocking?

[charles-lunarg]

I believe the crux of the problem is that GetWindowText is a thinly veiled SendMessage(WM_GETTEXT) which only returns when the message pump has processed the message, hence the deadlock. It may be possible to send such a request to the message queue and setup a callback.

Issue with this fix is simply "is it worth fixing versus rewriting the layer entirely?". The layer is very simple, which makes it nice as a quick & dirty FPS monitor, but it could contain breakdown of the FPS, frametime, variance, and all sorts of other features that the current monitor layer just can't do with a single titlebar. But of course, who's going to do that? Do other layers exists that do similar things, and should those layers be preferred? (aka shipped in the SDK). I don't have answers to those questions, only a vague gesturing towards "never enough time to do everything you want".