Reverting a merge is sticky: it tells git you never want to see that branch
again. Merging the DRTVWR-546 branch, which contained the revert, into the
glthread branch undid much of the development work on that branch. To restore
it we must revert the revert.
This reverts commit 029b41c041.
It can happen that we try to post() work for LLWindowWin32's window thread
after the thread's WorkQueue has been closed.
Also, instead of giving the "General" ThreadPool static lifespan, put it on
the heap, anchored with a static unique_ptr.
It's sometimes important to finish other initialization before launching the
threads in the ThreadPool, so make that an explicit step. In particular, we
were launching the LLImageGL texture thread before initializing the GL
context, resulting in all gray textures.
Add LLWindowWin32Thread::Post(), like post() except it uses PostMessage() to
send the work item to the window thread. Support this in mainWindowProc().
Move LLWindowWin32::recreateWindow()'s destroy_window_handler() call onto the
window thread. Delaying destruction of the old HWND ensures that we can use
PostMessage() and GetMessage() with that HWND to pass the lambda work item.
Moreover, it's likely to be less buggy to call DestroyWindow() on the same
thread that created the window.
Make recreateWindow()'s window thread lambda bind the window class parameters
by value, rather than binding 'this' and back-referencing LLWindowWin32
members.
Make recreateWindow() construct the window thread lambda and then decide
whether to pass it to the window thread using post() or Post(), depending on
whether we have a current HWND -- therefore whether the window thread is
blocked on GetMessage(). That means we can eliminate the kickWindowThread()
call.
Make destroy_window_handler() accept HWND by value rather than by non-const
reference. Since it doesn't attempt to modify the caller's value, this is a
better match for the function's semantics anyway -- but importantly, it lets
us pass a const HWND.
llwindowwin32.cpp's LLWinImm class used to dynamically load IMM32.DLL and
populate its methods using GetProcAddress(). That was to support Windows XP.
Since we've dropped Windows XP, use static linking instead, with dramatically
fewer lines of code (and less of a thread safety alarm trigger).
We retain the LLWinImm wrapper class only as a hook for Tracy instrumentation.
LLWindowWin32::mWndProc was a public WNDPROC member. If set non-NULL,
mainWindowProc() would call that before falling into its own handler code. But
now, mWndProc would be called on the window thread instead of on the main
thread. Running arbitrary callback code on the window thread could cause all
sorts of problems.
It could be made safe by posting the callback call to the "mainloop" WorkQueue
for execution on the main thread. But as no code actually references it,
delete it instead.
Per DaveP, the recent change to LLWindowsWin32Thread::post() could end up
calling PostMessage() many times per frame, with nontrivial overhead.
Reinstate the more selective code that calls PostMessage() with the dummy
message (to bust us out of GetMessage() to check pending window-thread work
requests) at most once per frame.
Move the whole LLWindowWin32Thread class inside LLWindowWin32, and make it a
struct. Migrate the struct declaration to llwindowwin32.cpp.
Derive it from ThreadPool, which provides the WorkQueue. Use runPending()
instead of manually popping and running individual queue items.
Make its post() operation always PostMessage(bogus) whenever we put an entry
in the WorkQueue, so we won't remain blocked in GetMessage().
Instead of storing a back pointer to the LLWindowWin32 instance, store the
relevant HWND and HDC in LLWindowWin32Thread itself to avoid cross-thread
timing problems.
Extract both instances of a large duplicated block of LLWindowWin32 code to a
new recreateWindow() method, and call it in those places. Per the TODO, use a
std::future to pass the new HWND and HDC back to LLWindowWin32 -- but also
store them locally on the LLWindowWin32Thread instance.
Ansariel