| Age | Commit message (Collapse) | Author |
|---|
|
|
|
DRTVWR-546
|
|
|
|
|
|
(decruftify settings, compatibility pass).
|
|
textures
|
|
drawpools.
|
|
remains from glod
|
|
|
|
remove unused variable
|
|
|
|
|
|
LLPipeline::shadersLoaded()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduce LLAppViewer::onCleanup(), a method that accepts a nullary callable
to execute once viewer shutdown begins. Fire the collected callables in
LLAppViewer::cleanup().
In llstartup.cpp, instead of declaring a static unique_ptr and relying on
static object destruction to clean up the "General" ThreadPool, bind the
pointer to the new ThreadPool into an onCleanup() lambda that will delete it
when called. ~ThreadPool() takes care of orderly shutdown.
|
|
Use hard tabs because most of the existing function uses those.
|
|
Use hard tabs as most of the class declaration already uses those.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Turns out that one of our WorkQueue integration tests was relying on the
incorrect runFor() behavior that we just fixed, so the test broke. Now that
runFor() doesn't wait around for work to be posted, use an explicit wait loop
instead.
To support this, add LLCond::get(functor), where functor must accept a const
reference to the stored data. This new get() returns whatever the functor
returns, allowing a caller to peek at the stored data.
Also use universal references for all remaining LLCond functor arguments.
|
|
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 029b41c0419e975bbb28454538b46dc69ce5d2ba.
|
|
runFor(interval) and runUntil(timestamp) are intended, and documented, to run
*no longer than* the specified time. Instead, the initial implementation
always waited the full specified time, hoping for work to arrive. Fix that:
once we clear work that's already pending, return right away.
|
|
|
|
|
|
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.
|
|
|
|
|
|
volatile members from LLVertexBuffer)
|
|
|
|
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.
|
|
and correspondingly, ll_convert<std::wstring>(const wchar_t*).
Now that we're using ll_convert() for single-argument stringize(arg), make
sure it can efficiently handle the simple case of constructing a string from a
const char pointer.
|
|
render target.
|
|
|
|
|
|
It's useful to be able to say STRINGIZE(item0 << item1 << item2), and we use
that a lot in our code base. But weird syntax aside, there are a couple
advantages to being able to write stringize(item0, item1, item2).
First, it allows stringize() to be used from within some other variadic
function, without having to make that function a macro that accepts an
arbitrary insertion-operator expression. There's no such thing as a member
macro.
Second, particularly for variadic functions, it allows us to optimize the
single-argument case stringize(item0). A macro can't do that. When item0 is
already a string of the desired char type, instead of streaming it into a
std::ostringstream and retrieving it again, we can simply return the input
string. When it's a pointer to the desired char type, we can directly
construct the result string without the help of std::ostringstream. When it's
a string of some other char type, we can engage ll_convert() to perform needed
conversions.
We generalize and optimize the generic gstringize() function, retaining the
role of stringize() and wstringize() as thin wrappers that merely provide the
desired char type.
Optimizing the single-argument case requires separately defining gstringize()
with two or more arguments: the general case. Then gstringize(arg) is
delegated to a gstringize_impl class template so we can partially specialize
to recognize a std::basic_string<desired_char_type> argument, as well as
desired_char_type*. Both these specializations engage ll_convert(), which
already handles the trivial case when no conversion is required.
Use of ll_convert() in this role supercedes and generalizes the previous
wstring_to_utf8str() and utf8str_to_wstring() overloads.
Also introduce stream_to(std::ostream&, ...) to support variadic streaming to
other destinations, e.g. a file, std::cout, ...
|
|
|
|
wglCreateContextAttribs call
|
|
|
