From e56d2c63c306dd087de26088729d09233b1122c2 Mon Sep 17 00:00:00 2001 From: Patric Stout Date: Wed, 24 Feb 2021 15:22:23 +0100 Subject: Add: [Video] move GameLoop into its own thread This allows drawing to happen while the GameLoop is doing an iteration too. Sadly, not much drawing currently can be done while the GameLoop is running, as for example PollEvent() or UpdateWindows() can influence the game-state. As such, they first need to acquire a lock on the game-state before they can be called. Currently, the main advantage is the time spend in Paint(), which for non-OpenGL drivers can be a few milliseconds. For OpenGL this is more like 0.05 milliseconds; in these instances this change doesn't add any benefits for now. This is an alternative to the former "draw-thread", which moved the drawing in a thread for some OSes. It has similar performance gain as this does, although this implementation allows for more finer control over what suffers when the GameLoop takes too long: drawing or the next GameLoop. For now they both suffer equally. --- src/video/win32_v.h | 2 ++ 1 file changed, 2 insertions(+) (limited to 'src/video/win32_v.h') diff --git a/src/video/win32_v.h b/src/video/win32_v.h index fc705c3f1..93ebdd83e 100644 --- a/src/video/win32_v.h +++ b/src/video/win32_v.h @@ -129,6 +129,8 @@ public: bool UseSystemCursor() override { return true; } + void PopulateSystemSprites() override; + void ClearSystemSprites() override; bool HasAnimBuffer() override { return true; } -- cgit v1.2.3-54-g00ecf