Age | Commit message (Collapse) | Author |
|
|
|
|
|
improvements can lead to perceived inventory loss due to cache corruption"
This reverts commit cf692c40b0b9f8d0d04cd10a02a84e3f697a2e99.
|
|
|
|
|
|
|
|
from U32*.
|
|
|
|
|
|
Pass llssize instead of S32.
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/llcharacter/llkeyframemotion.cpp
# indra/newview/llfilepicker.cpp
|
|
|
|
|
|
Rather than continuing to propagate try/catch (Closed)
(aka LLThreadSafeQueueInterrupt) constructs through the code base, make
WorkQueueBase::post() return bool indicating success (i.e. ! isClosed()).
This obviates postIfOpen(), which no one was using anyway.
In effect, postIfOpen() is renamed post(), bypassing the exception when
isClosed().
Review existing try/catch blocks of that sort, changing to test for post()
returning false.
|
|
catching and returning false
|
|
|
|
|
|
|
|
|
|
|
|
Newer C++ compilers have different semantics around LLSDArray's special copy
constructor, which was essential to proper LLSD nesting. In short, we can no
longer trust LLSDArray to behave correctly. Now that we have variadic
functions, get rid of LLSDArray and replace every reference with llsd::array().
|
|
|
|
The trouble with debugLoggingEnabled() is that it locked mutexes and searched
maps every time that call was reached. LL_DEBUGS() has the same functionality
(albeit with idiosyncratic syntax) but performs expensive lookups only once
per session, caching the result in a local static variable.
|
|
timer without a frame stall.
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/llfloateravatarrendersettings.cpp
|
|
|
|
|
|
# Conflicts:
# indra/cmake/CMakeLists.txt
# indra/newview/skins/default/xui/es/floater_tools.xml
|
|
lead to perceived inventory loss due to cache corruption
|
|
# Conflicts:
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
|
|
DRTVWR-559
|
|
implementations must not change, but may add "fast" variants where appropriate in the future.
|
|
|
|
|
|
As it happens, the change in the LLUUID::combine() algorithm introduced by one
of my previous commits is causing invalid assets creation (seen with
some clothing items, such as Shape and Universal types); obviously, the server
is using the old algorithm for UUID validation purpose of these assets.
This commit reverts LLUUID::combine() code to use LLMD5.
|
|
As it happens, the change in the LLUUID::combine() algorithm introduced by one
of my previous commits is causing invalid assets creation (seen with
some clothing items, such as Shape and Universal types); obviously, the server
is using the old algorithm for UUID validation purpose of these assets.
This commit reverts LLUUID::combine() code to use LLMD5.
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/newview/llfilepicker.h
# indra/newview/llfilepicker_mac.h
# indra/newview/llfilepicker_mac.mm
|
|
# Conflicts:
# doc/contributions.txt
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
|
|
|
|
|
|
|
|
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.
|