| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Disable NvAPI by default
|
|
Win7 is no longer supported and is below minimal requirements
|
|
|
|
|
|
A lot of reports about crashes in voice's removeObserver with no indication of the cause, all MAC specific. By this point terminate should have been called and mVoiceModule should be null, yet callstaks suggest it isn't.
Commit clears LLVoiceClient beforehand to avoid the issue entirely, but issue lies elsewhere and 'voice' crash is just a symptom.
|
|
|
|
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/newview/llfilepicker.h
# indra/newview/llfilepicker_mac.h
# indra/newview/llfilepicker_mac.mm
|
|
|
|
INTL-370 Translate the word Feed for new Viewer Profiles
|
|
following promotion of DRTVWR-570
|
|
|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|
|
This reverts commit 4d429b7ea31f51f653e0e2ad6b5799a515e28334.
|
|
|
|
|
|
|
|
Inspect and copy doesn't work for face or child selection. Disable them in such cases.
|
|
|
|
Viewer doesn't support web downloads, it should be safe to assume stream and play it
|
|
Fixes folders being invidible (missing arrange)
Fixes sroll to target not working reliably
|
|
D577 should have picked part of the changes from contribute branch, picking up the rest for the sake of branch specific crash fixes
|
|
|
|
Links can be drag and dropped so they should be movable via 'cut' as well
|
|
|
|
branches (#47)
Revert part of "DRTVWR-575: Address review comments on Xcode 14.1 type tweaks."
Crash was reproduced when assigning areastr to llsd, but likely present in other cases of assigning ui strings to llsd (instead of going for lluistring's result directly copy constructor was engaged and either copy or original crashed due to invalid pointers, copy shouldn't have been created).
|
|
Polish directory; Fix localizability in various English XMLs
|
|
This reverts commit d6f5e5bc9424b9d45f6eeeca5d894d46dc91b279.
|
|
|
|
user is in DND mode
Revert of commit for SL-15401. Messages are supposed to handle 'mute' on their own.
|
|
|
|
|
|
LLFloaterLandHoldings::postBuild() was constructing an LLSD structure by
assigning each map entry and array element one at a time. Chorazinallen
identified a crash bug possibly caused by destroying that LLSD structure.
Diagnostically try building it using nested llsd::map() and llsd::array()
calls instead to see if that improves matters.
|
|
It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:
some_LLSD_map[key] = LLSDArray(...)(...)...;
used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.
The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.
Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.
Tip of the hat to Chorazinallen for surfacing this issue!
|
|
|
|
density_ctrl.xml file
|
|
|
|
Server sends updates in bulk now, so notify per agent instead of per update
|
|
Fix failures to update the TP states while the viewer is minimized.
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/app_settings/shaders/class1/deferred/materialF.glsl
# indra/newview/llfloater360capture.cpp
|
|
following promotion of DRTVWR-565
|
|
|
|
|
|
|
|
|
|
|
