Age | Commit message (Collapse) | Author |
|
DRTVWR-583
|
|
|
|
# Conflicts:
# indra/llcommon/CMakeLists.txt
# indra/newview/llspatialpartition.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llvoavatar.cpp
|
|
with /bigobj
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/CMakeLists.txt
# indra/newview/VIEWER_VERSION.txt
# indra/newview/llagent.cpp
# indra/newview/llfloaternewfeaturenotification.cpp
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorymodel.cpp
# indra/newview/lloutfitgallery.cpp
# indra/newview/llpanelmaininventory.cpp
# indra/newview/llpanelmaininventory.h
# indra/newview/llsidepaneltaskinfo.cpp
# indra/newview/llsidepaneltaskinfo.h
# indra/newview/lltexturectrl.cpp
# indra/newview/lltexturectrl.h
# indra/newview/llviewerinventory.cpp
# indra/newview/llviewerobject.cpp
# indra/newview/llviewertexturelist.cpp
# indra/newview/llviewertexturelist.h
# indra/newview/skins/default/xui/en/floater_new_feature_notification.xml
# indra/newview/skins/default/xui/en/menu_inventory.xml
|
|
|
|
On Mac, in the CMake USE_BUGSPLAT logic, we created both xcarchive.zip (which
is what BugSplat wants to see) and secondlife-symbols-darwin -64.tar.bz2 (which
we don't think is used for anything). The tarball was posted to codeticket --
but why? If the point is to manually re-upload to BugSplat in case of failure,
we'll do better saving xcarchive.zip to codeticket.
For SL-19243, posting xcarchive.zip directly supports the goal of breaking out
the upload to BugSplat as a separate step.
Anyway, since xcarchive.zip is a superset of the tarball, the tarball can be
recreated from the zip file, whereas the zip file can't be recreated from the
tarball without opening the .dmg installer and extracting the viewer executable.
If the xcarchive.zip file exists (that is, on Mac), post that to codeticket or
GitHub, as applicable, instead of the tarball. In fact, in the USE_BUGSPLAT
case, don't even bother creating the tarball since we're going to ignore it.
Make the new build.sh logic that insists on BUGSPLAT_USER and BUGSPLAT_PASS
conditional on BUGSPLAT_DB.
|
|
|
|
Pulled in relevant parts from SL-19929
|
|
DRTVWR-583
|
|
|
|
# Conflicts:
# indra/newview/llappviewer.cpp
|
|
|
|
"object_id" to "local_id"
|
|
|
|
# Conflicts:
# indra/newview/llinventoryfunctions.cpp
# indra/newview/llpanelmaininventory.h
# indra/newview/skins/default/xui/en/floater_inventory_item_properties.xml
# indra/newview/skins/default/xui/en/sidepanel_item_info.xml
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
related SL-18684/SL-19206/SL-19173
|
|
|
|
|
|
|
|
|
|
Looks like it wasn't used for a while and LLFloaterItemPropertie does the same thing now
|
|
LLIconCtrl stores icons indefinitely which is undesired for fairly large and expected to be numerous thumbnails, LLTextureCtrl is tied to texture picker and has a number of limitations (already processes clicks, enforces label area). Intent behind LLThumbnailCtrl is to bridge the gap - to not store texture indefinitely and to allow further customisation.
|
|
wrong color space.
|
|
# Conflicts:
# indra/newview/llappearancemgr.cpp
# indra/newview/llpanelmaininventory.cpp
|
|
# 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
|
|
|
|
(or folder containing - among others - exactly one texture) and when hovering over notecard embedded textures
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llappviewer.cpp
# indra/newview/skins/default/colors.xml
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/app_settings/shaders/class1/deferred/materialF.glsl
# indra/newview/llfloater360capture.cpp
|
|
|
|
|
|
"Transparent Water" checkbox.
|
|
busted). WIP on reflection probe/PBR driven water shader.
|
|
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
|
|
|
|
|
|
Ansariel Hiller.
|
|
|