Age | Commit message (Collapse) | Author |
|
May also fix octree updates on mere material changes due to general refactoring.
|
|
|
|
octree updates by removing them from the static octree via makeActive
|
|
|
|
|
|
This reverts MAINT-1401, but looks like that was fixed properly later
|
|
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llviewercontrol.cpp
|
|
|
|
|
|
# Conflicts:
# indra/newview/llviewertexturelist.cpp
|
|
following promotion of DRTVWR-543
|
|
|
|
experience changes water settings.
|
|
Support 'button up' when losing focus
When releasing button far out of view or by refocusing something, button was not commiting. LLPanelObject last call was sendPosition(btn_down) with btn_down true which resulted in missed update. Now it will get one more call with btn_down==false.
|
|
SL-17329: Address Mac build error
Approved-by: Andrey Lihatskiy
|
|
|
|
|
|
|
|
SL-17329: Fix cache sizes due to overflow. Improve typing.
Approved-by: Andrey Lihatskiy
|
|
|
|
|
|
|
|
|
|
to 40%
|
|
|
|
so it doesn't affect the time measurement.
The time resolution of the debug log is in seconds, so it's not particularly useful.
Arguably, one could remove this fine logging in favor of Tracy markers. Or have both. Depends on the use case.
|
|
|
|
|
|
One important factor in the design of LazyEventAPI was the desire to allow
LLLeapListener to query metadata for an LLEventAPI even if it hasn't yet been
instantiated by LazyEventAPI. That's why LazyEventAPI requires the same
metadata required by a classic LLEventAPI.
Instead of just publicly exposing its data members, give LazyEventAPI a query
API mimicking LLEventAPI / LLEventDispatcher. Protect data members and private
methods.
Adapt lazyeventapi_test.cpp accordingly.
Extend LLLeapListener::getAPIs() and getAPI() to look through LazyEventAPIBase
instances after first checking existing LLEventAPI instances. Because the
query API for LazyEventAPIBase mimics LLEventAPI's, extract getAPI()'s actual
metadata reporting to a new internal template function reportAPI().
While we're touching LLLeapListener, we no longer need BOOST_FOREACH().
|
|
|
|
|
|
|
|
from 'force_update' to 'foce_treat_as_rigged'
|
|
inside an on-the-fly calculated bounding box.
Technically not a broadphase check, but better than calculating an octree for a bunch of meshes.
|
|
picking unless eligible for narrow-phase intersect check (fast broad-phase intersect pre-check not yet implemented)
|
|
animation is frozen
|
|
store elements in octrees as raw pointers. Use for faster allocation in LLVolumeFace::createOctree.
|
|
No performance difference measured
|
|
A classic LLEventAPI subclass calls LLEventDispatcher::add() methods in its
own constructor. At that point, addMethod() can reliably dynamic_cast its
'this' pointer to the new subclass.
But because of the way LazyEventAPI queues up add() calls, they're invoked in
the (new) LLEventAPI constructor itself. The subclass constructor body hasn't
even started running, and LLEventDispatcher::addMethod()'s dynamic_cast to the
LLEventAPI subclass returns nullptr. addMethod() claims the new subclass isn't
derived from LLEventDispatcher, which is confusing since it is.
It works to change addMethod()'s dynamic_cast to static_cast.
Flesh out lazyeventapi_test.cpp. post() maps with "op" keys to actually try to
engage the registered operation. Give the operation an observable side effect;
use ensure_mumble() to verify. Also verify that LazyEventAPI has captured the
subject LLEventAPI's metadata in a way we can retrieve.
|
|
|
|
|
|
|
|
|
|
deleting a classified
|
|
|
|
|
|
LazyEventAPI is a registrar that implicitly instantiates some particular
LLEventAPI subclass on demand: that is, when LLEventPumps::obtain() tries to
find an LLEventPump by the registered name.
This leverages the new LLEventPumps::registerPumpFactory() machinery. Fix
registerPumpFactory() to adapt the passed PumpFactory to accept TypeFactory
parameters (two of which it ignores). Supplement it with
unregisterPumpFactory() to support LazyEventAPI instances with lifespans
shorter than the process -- which may be mostly test programs, but still a
hole worth closing. Similarly, add unregisterTypeFactory().
A LazyEventAPI subclass takes over responsibility for specifying the
LLEventAPI's name, desc, field, plus whatever add() calls will be needed to
register the LLEventAPI's operations. This is so we can (later) enhance
LLLeapListener to consult LazyEventAPI instances for not-yet-instantiated
LLEventAPI metadata, as well as enumerating existing LLEventAPI instances.
The trickiest part of this is capturing calls to the various
LLEventDispatcher::add() overloads in such a way that, when the LLEventAPI
subclass is eventually instantiated, we can replay them in the new instance.
LLEventAPI acquires a new protected constructor specifically for use by a
subclass registered by a companion LazyEventAPI. It accepts a const reference
to LazyEventAPIParams, intended to be opaque to the LLEventAPI subclass; the
subclass must declare a constructor that accepts and forwards the parameter
block to the new LLEventAPI constructor. The implementation delegates to the
existing LLEventAPI constructor, plus it runs deferred add() calls.
LLDispatchListener now derives from LLEventStream instead of containing it as
a data member. The reason is that if LLEventPumps::obtain() implicitly
instantiates it, LLEventPumps's destructor will try to destroy it by deleting
the LLEventPump*. If the LLEventPump returned by the factory function is a
data member of an outer class, that won't work so well. But if
LLDispatchListener (and by implication, LLEventAPI and any subclass) is
derived from LLEventPump, then the virtual destructor will Do The Right Thing.
Change LLDispatchListener to *not* allow tweaking the LLEventPump name. Since
the overwhelming use case for LLDispatchListener is LLEventAPI, accepting but
silently renaming an LLEventAPI subclass would ensure nobody could reach it.
Change LLEventDispatcher's use of std::enable_if to control the set of add()
overloads available for the intended use cases. Apparently this formulation is
just as functional at the method declaration point, while avoiding the need to
restate the whole enable_if expression at the method definition point.
Add lazyeventapi_test.cpp to exercise.
|