6 Commits (f8c6034b93e9976458081a936dcc361ee08e440c)

Author	SHA1	Message	Date
Patric Stout	970fedd78c	Add: make modal windows update more smooth ... Basically, modal windows had their own thread-locking for what drawing was possible. This is a bit nonsense now we have a game-thread. And it makes much more sense to do things like NewGRFScan and GenerateWorld in the game-thread, and not in a thread next to the game-thread. This commit changes that: it removes the threads for NewGRFScan and GenerateWorld, and just runs the code in the game-thread. On regular intervals it allows the draw-thread to do a tick, which gives a much smoother look and feel. It does slow down NewGRFScan and GenerateWorld ever so slightly as it spends more time on drawing. But the slowdown is not measureable on my machines (with 700+ NewGRFs / 4kx4k map and a Debug build). Running without a game-thread means NewGRFScan and GenerateWorld are now blocking.	2021-03-10 13:41:18 +01:00
S. D. Cloudt	13cc8a0cee	Cleanup: Removed SVN headers	2019-11-10 17:59:20 +00:00
Michael Lutz	05f4e73608	Codechange: Replace custom mutex code with C++11 mutex'es. ... A conforming compiler with a valid <mutex>-header is expected. Most parts of the code assume that locking a mutex will never fail unexpectedly, which is generally true on all common platforms that don't just pretend to be C++11. The use of condition variables in driver code is checked.	2019-04-06 11:27:39 +02:00
rubidium	70179db81e	(svn r22820) -Codechange: perform a full (re)draw cycle in the first draw during progress instead of waiting 200ms	2011-08-24 12:18:53 +00:00
rubidium	38ad276acc	(svn r22819) -Fix: include the header where it should be included	2011-08-24 12:12:36 +00:00
rubidium	421053a694	(svn r22788) -Codechange: move modal progress related functions and variables to progress.cpp/h	2011-08-21 12:48:46 +00:00