| Age | Commit message (Collapse) | Author |
|---|
|
Checker: DEADCODE
Function: show_item_sharing_confirmation(std::basic_string<char, std::char_traits<char>, std::allocator<char>>, LLViewerInventoryItem *, const LLSD &, const LLUUID &, const LLUUID &)
File: /indra/newview/lltooldraganddrop.cpp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
often on openal lock)
Submitting a patch made by Aleric Inglewood (See VWR-14914).
This bug happens for a lot of people, although it might be needed to have a fast multi core machine.
I have seen it on 1.22.10 once, never used 1.23 sorry, and saw it often on snowglobe. I am sure
it also affects 1.23 but I'd have to test that.
The symptons are that on a viewer with normally a good, high FPS, sometimes it happens
that the FPS dramatically drops (as low as 0.3, but it can also be anything higher, as high
as 10, say).
This particular jira is about a problem where the main thread is slowed down by a mutex lock
in libopenal (most calls starting with 'al' in indra/llaudio/audioengine_openal.cpp and
one in indra/llaudio/listener_openal.cpp). You can see that this is the case by opening the
Frame Console (control-shift-2) and checking that the "audio" (and possibly misc) timings
are very large compared to the Render time.
|
|
fetch is in progress.
|
|
Submitting on behalf of Thickbrick Sleaford.
One of the LLSelectNode constructors has a leak where it does "new LLPermisions()" twice, thus leaking the address of the first object created.
This constructor is called every time you interact (click, hover, select, possibly other) with an object, once for each prim in the object. Since sizeof(LLPermissions) is 92 bytes, this can be a significant amount after a while.
I think this might explain VWR-18528 (leaking LLpemissions instances), at least partially.
This was fixed in snowglobe 1.x as part of SNOW-267.
|
|
|
|
Patch by Merov ported and reviewed by Tofu, from SG2.
|
|
|
|
enabled in settings
|
|
logged in
reviewed by Monroe
|
|
the other variant.
|
|
|
|
|
|
tools->Features.
|
|
|
|
|
|
all floaters).
The crash was introduced by my previous fix of this ticket in changeset 8ceebd3612f0.
The problem was that, suprisingly, even invisible (faded) toasts were destroyed when you hit Ctrl_Shift+W,
however they were still referenced by the toast pool, so the references were invalidated.
The easiest fix would be to remove all references to the toast being destroyed, no matter is it visible or not.
However, then we'd have to search for each destroyed toast in the pool, which is slow.
Besides, removing toasts from the pool compromises the whole idea of pooling (which was introduced to speed up creation of new toasts).
Another possible fix is not to destroy any nearby chat toasts when user hits Ctrl+Shift+W.
That would save us from any crashes at a price of changing existing behaviour (the toasts will remain visible).
So I went for a third option: when closing all floaters, skip invisible ones.
Then there won't be attempts to destroy invisible (pooled) toasts, so the crash won't happen,
and we don't seem to change any existing behavior.
However I'm not 100% sure of the latter statement, so the fix requires extensive testing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
opens a tiny window when all popups setting is enabled).
|
|
|
|
|
|
Profile SP even when no IM session is started with that resident.
|
|
|
|
|
|
|
|
|
|
also popup notification is no longer a singleton
|
|
|
|
|
|
inventory context menu for incomplete outfits.
|
|
|
|
Bug reason: The fix of EXT-1419 disables showing nearby chat showing toasts at all whenever you close one.
That was done to prevent a crash when viewer is exiting, but closing a toast manually should be handled differently.
Fix: If a toast is being closed (destroyed) manually, just remove it from the toast pool
(to prevent further references to the invalid pointer), but keep on showing new toasts.
I've overriden LLFloater::onClose() to differentiate the two cases.
|
|
trusted content is now a const attribute of LLMediaCtrl, set in constructor params
|
