mirror of
https://github.com/narzoul/DDrawCompat
synced 2024-12-30 08:55:36 +01:00
a573c1344c
Because both the DirectDraw and GDI thread locks are held by the thread that initially calls beginGdiRendering, a deadlock can occur if a complex rendering operation uses synchronized worker threads for some subtasks and they also need access to the resources locked by the initial thread. To resolve this, the GDI thread lock is no longer held after beginGdiRendering returns, and the DirectDraw thread lock is only taken during the initial entry. However, this introduces another problem, because now the final endGdiRendering might not be called by the same thread that initially called beginGdiRendering. If this happens, a deadlock will occur because the initial thread is still holding the DirectDraw thread lock while the other thread is trying to acquire it to unlock the primary surface. To resolve this, the initial thread will always be the one to release the lock on the primary surface, waiting for other threads to finish using GDI DCs if necessary. This also means that other threads won't be able to create new cached DCs (as they would need the DD thread lock), so to prevent yet another deadlock, the initial thread always preallocates a number of DCs in the cache, and only the initial thread is allowed to extend the cache.