| Age | Commit message (Collapse) | Author |
|---|
|
|
|
enable github actions mac nightly builds
|
|
|
|
|
|
|
|
errors (#194)
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/cmake/CMakeLists.txt
# indra/newview/skins/default/xui/es/floater_tools.xml
|
|
Should fix "Radio/Stream hiccups at a regular rate during playback"
|
|
# Conflicts:
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
|
|
perfomance SL-18563
```
autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110561/960415/tracy-v0.7.8.578230-darwin64-578230.tar.bz2" hash="70f31fa71ecb52bd092da52e27c3ff8c"
autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110562/960424/tracy-v0.7.8.578230-windows-578230.tar.bz2" hash="1dc33422939adf015db85e96c5a8276e"
autobuild installables edit "tracy" url="https://automated-builds-secondlife-com.s3.amazonaws.com/ct2/110563/960429/tracy-v0.7.8.578230-windows64-578230.tar.bz2" hash="fcc6ecece2ecb65aa36500dfa9461fb3"
```
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/newview/llfilepicker.h
# indra/newview/llfilepicker_mac.h
# indra/newview/llfilepicker_mac.mm
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
# Conflicts:
# autobuild.xml
# indra/newview/llagent.cpp
# indra/newview/llimview.cpp
# indra/newview/llimview.h
# indra/newview/llinventoryfunctions.cpp
# indra/newview/llpanelmediasettingsgeneral.cpp
# indra/newview/pipeline.cpp
|
|
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/app_settings/shaders/class1/deferred/materialF.glsl
# indra/newview/llfloater360capture.cpp
|
|
|
|
|
|
|
|
|
|
Same apr suit version, but with debug symbols
|
|
|
|
|
|
|
|
part of SL-17967 work for material overrides
|
|
Should fix some common crashes for parcel media
|
|
|
|
as the generator string for Windows builds
|
|
|
|
enable partial bitstreams
Openjpeg was modified: "p_max_len -= l_nb_bytes_read;" was causing an overflow.
I'm not sure if I did something incorectly in opj_skip/opj_seek viewer side, but seems like openjpeg should have been checking remaining space in p_max_len either way.
P.S. Many thanks to Chafey and Neopallium for implementing openjpeg's partial bitstream support
|
|
|
|
|
|
DRTVWR-568_cmake
|
|
|
|
# Conflicts:
# indra/newview/llpanelface.cpp
# indra/newview/llpanelface.h
|
|
|
|
Viewer part of the fix for this JIRA - pulls in the updated Dullahan that exposes the user_gesture/is_redirect flags and uses them to determine what type of 'nav_type' is exchanged with viewer/plugin
|
|
switch to per-pixel binormal generation. Still bugged with some test content.
|
