| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(cherry picked from commit 18de6c9b989cc7060f2a314f5b68cc102677823b)
|
|
instead of requiring a separate declaration for each subclass.
The previous way produces errors in clang.
(cherry picked from commit 8458ad8890cf0a11804996210d7bcfbdaa3eec2e)
|
|
even if idle() exits early.
|
|
Avatar wasn't reflecting but distorting, since avatar was already under water it looked like a 'reflection' of avatar, but was not rotated right and with wrong angle.
|
|
|
|
Make avatar cloud delay longer proportionally to load time
|
|
|
|
|
|
|
|
|
|
|
|
in stats window
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/app_settings/settings.xml
|
|
# Conflicts:
# indra/newview/VIEWER_VERSION.txt
|
|
# Conflicts:
# README.md
|
|
following promotion of DRTVWR-545
|
|
mHasGeneratedFaces is always true for some types of models and glod was treating faces as one mesh by default, so meshoptimizer should do the same regardles of mHasGeneratedFaces
|
|
before blocking on the pending future. Otherwise the window thread can remain
blocked in a GetMessage() call and deadlock the app.
|
|
This reverts commit 5188a26a8521251dda07ac0140bb129f28417e49, reversing
changes made to 819088563e13f1d75e048311fbaf0df4a79b7e19.
|
|
|
|
|
|
|
|
|
