| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
crash logger.
This is a patch originally written by Robin Cornelius.
I made it work with Google Breakpad.
|
|
|
|
teleport is on, allow beacon setting if not
|
|
LLTextBase::setCursor() sometimes failed to work properly if line wrapping was enabled.
This is a slightly optimized version of the patch made by Satomi Ahn.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The point of this patch is to make the Mac updater code a bit more flexible
and reliable than it is right now. The issue is double:
* reliability: the string comparison code on the bundle identifier is not UTF8 compliant
* flexibility: the bundle identifier is hard coded to match the bundle identifier of LL viewer
(i.e. com.secondlife.indra.viewer) so it can't work for another viewer
(in particular, it didn't work for Snowglobe).
The "bundle identifier" is one of those Mac only thing stored in the Info.plist of a "bundle"
(the ".app" folder that's bundling an executable and all its resources and is seen
as an application when browsing with the Mac OS X Finder).
The patch fixes both issues:
* compare correctly UTF8 encoded strings
* allow the bundle ID to be passed as a parameter to the updater
The patch has really no consequence on LL viewer. It's more a matter of having cleaner, better code.
Author: Cypren Christenson
Ported and reviewed by: Merov Linden
|
|
lldarray.h
Author: Robin Cornelius
Ported by: Techwolf Lupindo
Reviewed by: Merov Linden
|
|
|
|
against Boost-1.42)
|
|
command line options are given
used Aleric's SG2 changeset from http://svn.secondlife.com/trac/linden/changeset/3600
patching file doc/contributions.txt
Hunk #1 succeeded at 73 with fuzz 2.
patching file indra/newview/llcommandlineparser.cpp
Hunk #1 succeeded at 268 with fuzz 1 (offset -8 lines).
Edited doc/contributions.txt to create an entry for Aleric and moved the
issue ID there (patch wasn't able to place it at the right position,
lacking any context).
|
|
|
|
|
|
|
|
|
|
for unit tests)
|
|
|
|
Used patch from https://jira.secondlife.com/secure/attachment/41586/SNOW-756-standalone_tests.diff
patching file indra/cmake/LLAddBuildTest.cmake
Hunk #1 succeeded at 259 with fuzz 2 (offset 1 line).
Added entry in doc/contributions.txt. No further changes.
originally commited to Snowglobe 2.1 at http://svn.secondlife.com/trac/linden/changeset/3515
|
|
viewer_manifest.py)
|
|
|
|
viewer_manifest.py Breaking linux 64-bit build.
(transplanted https://bitbucket.org/Techwolf/viewer-development/changeset/111a293c0e1c to create an isolated daggy fix)
|
|
|
|
Daggified version of http://svn.secondlife.com/trac/linden/changeset/3431
(or of the SNOW-654 part of https://bitbucket.org/Techwolf/viewer-development/changeset/5697874b390b )
|
|
indra/llplugin/slplugin/CMakeLists.txt
|
|
Daggified version of http://svn.secondlife.com/trac/linden/changeset/3523
(or of the SNOW-651 part of https://bitbucket.org/Techwolf/viewer-development/changeset/5697874b390b )
|
|
showing up.
This will also take care of STORM-221 since the person that would be affected by
the toast cha now disable them.
|
|
|
|
|
|
|
|
|
|
related to "audio" (main thread hangs often on openal lock)
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
