The issues was introduced with
this commit which is an essential part of indexed vertex buffer usage for flats rendering.
Honestly I have no idea why it causes such horrendous lags on macOS.
But the strangest thing in this bug is the workaround.
If GZDoom is started as usual (without mods or with a mod that doesn't have title map), each frame takes up to 500 ms to render.
If the game is started with
+map ... command line (or with a title map), the issue doesn't appear.
Moreover, integrated Intel graphics seem to be unaffected by this thing at all. Only discrete one exhibits the huge difference in performance.
Ideas are welcome. I tried to play with
usage arguments of
glBufferData in gl_vertexbuffer.cpp but this didn't change anything. Or perhaps I didn't manage to find the right combination.
The issues was introduced with [url=https://github.com/coelckers/gzdoom/commit/fd3681dae22e6fa41841d7e37b66c3f4aff7d481]this commit[/url] which is an essential part of indexed vertex buffer usage for flats rendering.
Honestly I have no idea why it causes such horrendous lags on macOS.
But the strangest thing in this bug is the workaround.
If GZDoom is started as usual (without mods or with a mod that doesn't have title map), each frame takes up to 500 ms to render.
If the game is started with [b]+map ...[/b] command line (or with a title map), the issue doesn't appear.
Moreover, integrated Intel graphics seem to be unaffected by this thing at all. Only discrete one exhibits the huge difference in performance.
Ideas are welcome. I tried to play with [i]usage[/i] arguments of [b]glBufferData[/b] in gl_vertexbuffer.cpp but this didn't change anything. Or perhaps I didn't manage to find the right combination.