Age | Commit message (Collapse) | Author |
|
|
|
following promotion of DRTVWR-500
|
|
|
|
|
|
# Conflicts:
# indra/newview/pipeline.cpp
|
|
following promotion of DRTVWR-440
|
|
|
|
|
|
|
|
water Fresnel
|
|
|
|
|
|
|
|
|
|
|
|
Fix light falloff being corrupted when editing value via build floater spinner
Approved-by: Dave Houlton
|
|
Fix editing light color corrupting intensity and color values
Approved-by: Dave Houlton
|
|
|
|
|
|
|
|
|
|
SL-12902 Better fix for light color values in color swatch not matching light color values inworld.
|
|
light color values inworld.
|
|
|
|
|
|
WRT light color values.
|
|
|
|
The new LLCoros::Stop exception is intended to terminate long-lived coroutines
-- not interrupt mainstream shutdown processing. Only throw it on an
explicitly-launched coroutine.
Make LLCoros::getName() (used by the above test) static. As with other LLCoros
methods, it might be called after the LLCoros LLSingleton instance has been
deleted. Requiring the caller to call instance() implies a possible need to
also call wasDeleted(). Encapsulate that nuance into a static method instead.
|
|
|
|
Earlier versions of macOS manifested frustrating problems in finishing the
built package. Those build steps seem to have been behaving better for a few
years now. Eliminate (what we fervently hope has become) a bit of ancient cruft.
|
|
That way, if there's a problem, a developer can rerun the same command.
|
|
However, this is not the right moment to perform that refactoring.
|
|
|
|
|
|
|
|
Also forget obsolete references to VS 2010 runtime DLLs.
|
|
|
|
LLAppViewer's heap LLWatchdogTimeout might be destroyed very late -- as late
as in LLAppViewer's destructor. By that time, LLAppViewer::cleanup() has
already called LLSingletonBase::deleteAll(), destroying the LLWatchdog
LLSingleton instance.
But LLWatchdogTimeout isa LLWatchdogEntry, and ~LLWatchdogEntry() calls
stop(), and stop() tries to remove that instance from LLWatchdog, thus
inadvertently resurrecting the deleted LLWatchdog. Which is pointless because
the resurrected LLWatchdog has never heard of the LLWatchdogTimeout instance
trying to remove itself.
Defend LLWatchdogEntry::stop() against the case in which LLWatchdog has
already been deleted.
|
|
Add ndof_dump_list() call, to enumerate available devices, when
ndof_init_first() returns failure.
Add "joystick" tags to existing LL_INFOS() (etc.) calls in
llviewerjoystick.cpp to make it easier to enable and disable such log
messages.
Add a specialized operator<<() function to log the contents of an NDOF_Device
struct. Add a couple LL_DEBUGS() calls for more visibility into library
operations.
|
|
Instead of heap-allocating a CoroData instance per coroutine, storing the
pointer in a ptr_map and deleting it from the ptr_map once the
fiber_specific_ptr for that coroutine is cleaned up -- just declare a stack
instance on the top-level stack frame, the simplest C++ lifespan management.
Derive CoroData from LLInstanceTracker to detect potential name collisions and
to enumerate instances.
Continue registering each coroutine's CoroData instance in our
fiber_specific_ptr, but use a no-op deleter function.
Make ~LLCoros() directly pump the fiber scheduler a few times, instead of
having a special "LLApp" listener.
|
|
which performs "by hand" the same sequence of calls found in stepFrame().
Why not simply call stepFrame()? Hysterical reasons?
|
|
Overriding virtual LLEventPump::flush() for the semantic of discarding
LLEventMailDrop's queued events turns out not to be such a great idea, because
LLEventPumps::flush(), which calls every registered LLEventPump's flush()
method, is called every mainloop tick. The first time we hit a use case in
which we expected LLEventMailDrop to hold queued events across a mainloop tick,
we were baffled that they were never delivered.
Moving that logic to a separate method specific to LLEventMailDrop resolves
that problem. Naming it discard() clarifies its intended functionality.
|
|
The LLEventMailDrop used to communicate with the Vivox coroutine is a member
of LLVivoxVoiceClient. We don't need to keep looking it up by its string name
in LLEventPumps.
|
|
|
|
|
|
|
|
Poller.
|
|
|
|
|
|
|