summaryrefslogtreecommitdiff
path: root/indra/newview
AgeCommit message (Collapse)Author
2017-06-06MAINT-7447 FIXED Selecting a group ability refreshes the list and deselects ↵Mnikolenko Productengine
your choice
2017-06-02MAINT-7459 Fixed incorrect 'Parcel owners can be more restrictive' checkbox ↵AndreyL ProductEngine
focus behavior
2017-05-30MAINT-731 Fixed Images Do Not Show at Proper Proportionsandreykproductengine
2017-06-01Mac buildfixAndreyL ProductEngine
2017-05-31MAINT-7325 Fixed issue of images being marked as missing due to ↵andreykproductengine
uninitialized discard level
2017-05-31MAINT-321 If Spin option is turned on, user cannot lift an object using Ctrl ↵daianakproductengine
button + Mouse
2017-05-24SL-702: refactor to make the viewer-manager easier for TPVs to integrateOz Linden
2017-05-24MAINT-4375 Viewer saves an empty snapshots if disk is fulldaianakproductengine
2017-05-30MAINT-7356 Feature - Force item delete warning to prompt once per sessionpavelkproductengine
2017-05-31MAINT-7455 Update Viewer Login error messageMnikolenko Productengine
2017-05-29MAINT-7438 FIXED Always allow 'create landmark' allows group teleport ↵Mnikolenko Productengine
routing override, however was removed.
2017-05-24MAINT-4375 Viewer saves an empty snapshots if disk is fulldaianakproductengine
2017-05-23pull from gateGlenn Glazer
2017-05-23DRTVWR-418: Reconcile new code with new Alex Ivy LLPipeline API.Nat Goodspeed
2017-05-22Automated merge with ssh://bitbucket.org/lindenlab/viewer-releaseNat Goodspeed
2017-05-22mergeBrad Payne (Vir Linden)
2017-05-22increment viewer version to 5.0.6Oz Linden
2017-05-17nerf launch from NSISGlenn Glazer
2017-05-17MAINT-7274 Remove "identifier" arg from the messageMnikolenko Productengine
2017-05-16MAINT-7414 FIXED Confirmation is not shown when removing multiple items at ↵Mnikolenko Productengine
once when above InventoryTrashMaxCapacity limit
2017-05-15MAINT-7383 show notifications for Purge item action in all inventory panelsMnikolenko Productengine
2017-05-15MAINT-7413 Display confirmation dialog after clicking Empty Trash on Trash ↵Mnikolenko Productengine
floater
2017-05-12pull from v64 gateGlenn Glazer
2017-05-11MAINT-7403 Disallow emptying Trash while in the Recent tab of InventoryMnikolenko Productengine
2017-05-10MAINT-7359 improve new Avatar Render Settings windowMnikolenko Productengine
2017-05-09MAINT-7343 - improved error case handling and checking for unlikely cornersBrad Payne (Vir Linden)
2017-05-08MAINT-7354 correction to misbehaving 'purge' and notification spam.andreykproductengine
2017-05-08DRTVWR-418: Fix vector assignment for C++03.Nat Goodspeed
For the time being we're still compiling for production with C++03. Although assigning an initializer list to a vector is valid C++11, in C++03 mode clang rejects it.
2017-05-05pull from gatecoyot@coyot-sager-PC.hsd1.ca.comcast.net
2017-05-04Automated merge with ssh://bitbucket.org/lindenlab/viewer64-c-11Nat Goodspeed
2017-05-04SL-617: use final_exe to create exe name in summary.jsoncoyot@coyot-sager-PC.hsd1.ca.comcast.net
2017-05-04Automated merge with ssh://bitbucket.org/lindenlab/viewer64Nat Goodspeed
2017-05-03Automated merge with ssh://bitbucket.org/lindenlab/viewer64Nat Goodspeed
2017-05-03DRTVWR-418: 64-bit Windows viewer requests "win64" updates from VVM.Nat Goodspeed
This is only transitional, until we integrate the Viewer Management Process (soon now).
2017-05-03Automated merge with ssh://bitbucket.org/lindenlab/viewer64Nat Goodspeed
2017-05-03MAINT-6928: upgrade VMP package to 504920 and rip out viewer-manifest ↵Glenn Glazer
changes for 2.6
2017-05-02Automated merge with head of lindenlab/viewer64callum@lindenlab.com
2017-05-02SL-617: use the braces, Luke!coyot@coyot-sager-PC.hsd1.ca.comcast.net
2017-05-02DRTVWR-418, MAINT-6996: clarify divide-by-1024 (not shift-right 10)Nat Goodspeed
2017-05-02DRTVWR-418, MAINT-6996: Rationalize LLMemory wrt 64-bit support.Nat Goodspeed
There were two distinct LLMemory methods getCurrentRSS() and getWorkingSetSize(). It was pointless to have both: on Windows they were completely redundant; on other platforms getWorkingSetSize() always returned 0. (Amusingly, though the Windows implementations both made exactly the same GetProcessMemoryInfo() call and used exactly the same logic, the code was different in the two -- as though the second was implemented without awareness of the first, even though they were adjacent in the source file.) One of the actual MAINT-6996 problems was due to the fact that getWorkingSetSize() returned U32, where getCurrentRSS() returns U64. In other words, getWorkingSetSize() was both useless *and* wrong. Remove it, and change its one call to getCurrentRSS() instead. The other culprit was that in several places, the 64-bit WorkingSetSize returned by the Windows GetProcessMemoryInfo() call (and by getCurrentRSS()) was explicitly cast to a 32-bit data type. That works only when explicitly or implicitly (using LLUnits type conversion) scaling the value to kilobytes or megabytes. When the size in bytes is desired, use 64-bit types instead. In addition to the symptoms, LLMemory was overdue for a bit of cleanup. There was a 16K block of memory called reserveMem, the comment on which read: "reserve 16K for out of memory error handling." Yet *nothing* was ever done with that block! If it were going to be useful, one would think someone would at some point explicitly free the block. In fact there was a method freeReserve(), apparently for just that purpose -- which was never called. As things stood, reserveMem served only to *prevent* the viewer from ever using that chunk of memory. Remove reserveMem and the unused freeReserve(). The only function of initClass() and cleanupClass() was to allocate and free reserveMem. Remove initClass(), cleanupClass() and the LLCommon calls to them. In a similar vein, there was an LLMemoryInfo::getPhysicalMemoryClamped() method that returned U32Bytes. Its job was simply to return a size in bytes that could fit into a U32 data type, returning U32_MAX if the 64-bit value exceeded 4GB. Eliminate that; change all its calls to getPhysicalMemoryKB() (which getPhysicalMemoryClamped() used internally anyway). We no longer care about any platform that cannot handle 64-bit data types.
2017-05-01Fix MAINT-7360 Investigate removal of MSVCR100.DLL and MSVCP100.DLLCallum Prentice
2017-05-01MAINT-7343 - removed unusued coprocedure parameter, changed one coro ↵Brad Payne (Vir Linden)
argument to pass by value
2017-05-01SL-617: fix registry pathcoyot@coyot-sager-PC.hsd1.ca.comcast.net
2017-04-28MAINT-7343 - moved asset downloads to use coprocedure pools, which should ↵Brad Payne (Vir Linden)
reduce the size of potential memory spikes
2017-04-28SL-617: pass final_exe from viewer manifest to NSIS as VIEWER_EXEcoyot@coyot-sager-PC
2017-04-28SL-671: fix string substitutioncoyot@coyot-sager-PC
2017-04-28SL-671: make icon point to launcher, not viewercoyot@coyot-sager-PC
2017-04-27DRTVWR-418: initSingleton(), cleanupSingleton() must be non-static.Nat Goodspeed
2017-04-27DRTVWR-418: Use conventional LLSingleton init/cleanup for LLWinDebug.Nat Goodspeed
LLWinDebug, though an LLSingleton, had (and required explicit calls to) special init() and cleanup() methods. Kitty Barnett points out that the cleanup() method was actually being called after LLSingletonBase::deleteAll(), requiring resurrection of the deleted LLWinDebug, which sometimes led to crashes. (Resurrecting deleted LLSingletons is always suspect.) Change LLWinDebug::init() and cleanup() to the conventional initSingleton() and cleanupSingleton() methods. This eliminates the need to make special method calls at all. In particular, cleanupSingleton() will be called by the existing LLSingletonBase::cleanupAll() call near viewer shutdown. We retain the early LLWinDebug::instance() call, which implicitly initializes the LLWinDebug instance, because evidently we want that initialized early. But we no longer require a separate init() call.
2017-04-27DRTVWR-418: Remove misleading comment -- no more implicit deleteAll().Nat Goodspeed
The comment indicates that calling LLSingletonBase::deleteAll() is optional because the LLSingleton machinery implicitly calls that during final static-object cleanup. That is no longer true.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-06 13:41:29 +0000