Age | Commit message (Collapse) | Author |
|
|
|
|
|
# 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
|
|
# 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.
|
|
# 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
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
into autobuild.xml for VS 2022 and update cmake script to copy the MSVC runtime (proper fix coming
|
|
libraries: replace hard coded VS 2017 '150' maginc number with another magic number - for VS 2019
|
|
|
|
DRTVWR-543-maint_cmake
|
|
# Conflicts:
# indra/llprimitive/llmodel.cpp
# indra/llprimitive/llmodel.h
# indra/newview/llappviewer.cpp
# indra/newview/llappviewer.h
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/cmake/LLCommon.cmake
# indra/llcommon/CMakeLists.txt
# indra/llrender/llgl.cpp
# indra/newview/llappviewer.cpp
# indra/newview/llface.cpp
# indra/newview/llflexibleobject.cpp
# indra/newview/llvovolume.cpp
|
|
|
|
|
|
# Conflicts:
# indra/llcommon/llsdutil.cpp
# indra/newview/VIEWER_VERSION.txt
# indra/newview/lldrawpoolalpha.cpp
# indra/newview/lldrawpoolwater.cpp
|
|
DRTVWR-543-maint_cmake
|
|
# Conflicts:
# indra/newview/app_settings/settings.xml
# indra/newview/llfloatersearch.cpp
# indra/newview/llgroupactions.cpp
# indra/newview/llvovolume.cpp
|
|
|
|
- Add the configuratons Release and ReleaseOS
- The js files are platform independent, just copy the ones from windows64.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nicky Dasmijn's contribution for zlib-ng Linux builds
|