Age | Commit message (Collapse) | Author |
|
|
|
|
|
threads and fix various crashes (#2079)
|
|
Fix two rare shutdown crashes in gCacheName and gObjectList
|
|
|
|
|
|
|
|
|
|
|
|
Previous pyramid walking calculation (#2032) assumed the incoming components variable can be accurate but unfortunately the needs_aux is only set to true if the face has an alpha mask setting.
Without this information we must assume the J2C files have the maximum component size of four so that alpha channels are found when decoding both the color and aux textures.
|
|
Fix for tracy build.
|
|
|
|
|
|
|
|
Allow `LLEventPump` listener access to its own `LLBoundListener`.
|
|
We used to allow "tweaking" the name. Don't.
|
|
`LLEventAPI` is specifically intended to allow a LEAP plugin, or a Lua script,
to access certain viewer functionality. Errors in external code like that
cannot be addressed during viewer development. Any code path that allows
external code in any form to crash the viewer opens up a potential abuse
vector, if a trusting user runs external code from an untrustworthy source.
`LLDispatchListener` reports exceptions back to its invoker, if the invoker
provides a "reply" `LLEventPump` name. Absent "reply", though,
`LLDispatchListener` is documented to let any such exception propagate. That
behavior may be okay for internal use, but in the case of the `LLEventAPI`
subclass, it veers into the abuse scenario described above.
Make `LLEventAPI` ensure that any exception propagating from `LLDispatchListener`
is caught and logged, but not propagated.
Also enrich error reporting for the "batch" `LLDispatchListener` operations.
|
|
Remove documented `LLEventPump` support for `LLEventTrackable`. That claimed
support was always a little bit magical/fragile. IF:
* a class included `LLEventTrackable` as a base class AND
* an instance of that class was managed by `boost::shared_ptr` AND
* you passed one of that class's methods and the `boost::shared_ptr`
specifically to `boost::bind()` AND
* the resulting `boost::bind()` object was passed into `LLEventPump::listen()`
THEN the promise was that on destruction of that object, that listener would
automatically be disconnected -- instead of leaving a dangling pointer bound
into the `LLEventPump`, causing a crash on the next `LLEventPump::post()` call.
The only existing code in the viewer code base that exercised `LLEventTrackable`
functionality was in test programs. When the viewer calls `LLEventPump::listen()`,
it typically stores the resulting connection object in an `LLTempBoundListener`
variable, which guarantees disconnection on destruction of that variable.
The fact that `LLEventTrackable` support is specific to `boost::bind()`, that it
silently fails to keep its promise with `std::bind()` or a lambda or any other
form of C++ callable, makes it untrustworthy for new code.
Note that the code base still uses `boost::signals2::trackable` for other
`boost::signals2::signal` instances not associated with `LLEventPump`. We are
not changing those at this time.
|
|
`listen()` still takes `LLEventListener`, a `callable(const LLSD&)`, but now
also accepts `LLAwareListener`, a `callable(const LLBoundListener&, const LLSD&)`.
This uses `boost::signals2::signal::connect_extended()`, which, when the
signal is called, passes to a connected listener the `LLBoundListener` (aka
`boost::signals2::connection`) representing its own connection. This allows a
listener to disconnect itself when done.
Internally, `listen_impl()` now always uses `connect_extended()`. When passed
a classic `LLEventListener`, `listen()` wraps it in a lambda that ignores the
passed `LLBoundListener`.
`listen()` also now accepts `LLVoidListener`, and internally wraps it in a lambda
that returns `false` on its behalf.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Split updates into batches that respect server update limit
|
|
# Conflicts:
# autobuild.xml
|
|
release/2024.06-atlasaurus
# Conflicts:
# autobuild.xml
# indra/newview/llvoicechannel.cpp
|
|
|
|
# Conflicts:
# autobuild.xml
|
|
|
|
|
|
LLScrollingPanelList::updatePanelVisiblilty()(220)
|
|
* Fix: Update calcDataSizeJ2C to pyramid-base file size estimation
Used the loop from the previous LayerFactored method to create a more accurate file size estimation by walking up the pyramid tiles.
Sizes are much larger in many cases and eliminate partial decoder issues with OpenJPEG.
KDU not tested but expected to produce better files as well.
Should also stop decode failures on tiny or very rectangular dimensions.
---------
Co-authored-by: Andrey Lihatskiy <alihatskiy@productengine.com>
|
|
2048x2048 (#2025)
|
|
|
|
|
|
|
|
|
|
Textures were being set to Inactive even if still in scene, causing them to be deleted and re-decoded in a loop.
|
|
|
|
gcc complains about this iterator not being const
|
|
gcc detects usage of this array as uninitialized, so make sure it's initialized. I am not sure if this is a legitimate warning, or if the code guarantees the array gets initialized before use in lines 140-142 and this is a performance optimization.
|
|
Show description and actual value of LLSD type setting
|
|
|
|
|
|
|
|
Revert "secondlife/viewer#1885: Terrain texture repeats: Remove feature flag dependency on simulator feature in favor of cap"
|