Age | Commit message (Collapse) | Author |
|
CoCreateInstance returns 'no interface supported'
Preferable not to mix init types so switched everything.
|
|
|
|
|
|
Incidental fix for crash when mWaterPool is null.
|
|
This PR fixes the non-working material hashing for LLGLTFMaterial instances.
There are several issues in the current code, stemming to the fact that the hashing is performed on the block of the member variables:
1.- There are padding bytes between member variables, even after rearranging them to avoid most of the padding; in particular, the std::array's size is not a multiple of 4 bytes (64 bits), and most compilers will pad them to the next 4-byte aligment as a result. Note that C++ standards do not impose the zeroing of padding bytes on construction of a class instance, with only a couple exceptions (such as explicit zero-initialization). Those bytes MUST therefore be zeroed by us on construction.
2.- The TextureTransform strutcure getPacked() method did not touch some of the packed bytes, and as a result could *potentially* cause an issue for hashing when applied to a transform of another material instance.
3.- With the recent addition of the local textures tracking map, the said map cannot be hashed as a block of memory (map pairs will typically be allocated on the heap or on the stack, not in the memory block used by member variables).
This PR solves all these issues and offers proper hashing of LLGLTFMaterial instances.
|
|
|
|
|
|
- Move it to the back unless requested by floater
(prioritize main inventory)
- Instead of fetching whole folder which likely has pending changes
from web side, fetch folder individually, then fetch changed content
in bulk
|
|
If fetch failed for some reason, old version would cause excessive
rerequests.
|
|
|
|
Might be better to have a separate set of states for 'fetched children'
or 'all children complete' inside the folder itself.
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llfloaterimcontainer.cpp
|
|
|
|
|
|
SL-20611 Make haze effect local lights. Incidental fix for EventPump coroutine sometimes doing unsafe work mid-render.
|
|
eye/object above/below water.
|
|
eye/object above/below water.
|
|
|
|
|
|
|
|
LLEventPoll hack.
|
|
|
|
|
|
# Conflicts:
# indra/newview/llinventorygallery.cpp
# indra/newview/skins/default/xui/en/notifications.xml
|
|
|
|
on macOS
|
|
|
|
|
|
# Conflicts:
# indra/llrender/llgl.cpp
# indra/llrender/llvertexbuffer.cpp
# indra/llui/llflatlistview.cpp
# indra/newview/app_settings/settings.xml
# indra/newview/lldrawpoolground.cpp
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorygallery.cpp
# indra/newview/llspatialpartition.cpp
# indra/newview/llviewercontrol.cpp
# indra/newview/llviewertexture.cpp
# indra/newview/llvosky.cpp
# indra/newview/skins/default/xui/en/menu_inventory.xml
|
|
# Conflicts:
# indra/llrender/llgl.cpp
# indra/llrender/llvertexbuffer.cpp
# indra/llui/llflatlistview.cpp
# indra/newview/lldrawpoolground.cpp
# indra/newview/llspatialpartition.cpp
# indra/newview/lltexturefetch.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llviewertexture.cpp
# indra/newview/llvosky.cpp
# indra/newview/skins/default/xui/en/floater_preferences_graphics_advanced.xml
# indra/newview/skins/default/xui/en/floater_stats.xml
# indra/newview/skins/default/xui/en/floater_texture_fetch_debugger.xml
# indra/newview/skins/default/xui/en/notifications.xml
# indra/newview/skins/default/xui/en/panel_performance_preferences.xml
|
|
This reverts commit b07a9cfec36cdcad604b8aa775ed282793116a4d
to fix SL-20649 "Seeing tiny hands on other avatars"
|
|
|
|
|
|
|
|
|
|
|
|
attached object
|
|
# Conflicts:
# indra/llcommon/CMakeLists.txt
# indra/newview/llspatialpartition.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llvoavatar.cpp
|
|
|
|
|
|
|
|
|
|
|
|
do properly user-mappable keys
|
|
Due to odd crashes when cleaning mItems adding thread safety
Viewer runs window in a separate thread, it is possible notification
was added in a way that corrupted the list.
|
|
Crash appears to happens inside mItems.clear() of the
LLNotificationChannelBase, but there is no apparent reson for it and
stack jumped some steps, so I'm doing cleanup more explicitly to see
if it's indeed there and not a corruption somewhere earlier.
|
|
Co-authored-by: Yuzuru Kato <pascal.imac@gmail.com>
Co-authored-by: Andrey Lihatskiy <alihatskiy@productengine.com>
|