summaryrefslogtreecommitdiff
path: root/indra/newview/llappviewer.cpp
AgeCommit message (Collapse)Author
2017-03-06merge changes for 5.0.2-releaseOz Linden
2017-02-27Look for logcontrol-dev.xml in the user settings directoryOz Linden
2017-01-27MergeRider Linden
2017-01-26MAINT-7082: Clean up, remove log spam.Rider Linden
2017-01-26MAINT-7082: max_idle_time unused.Rider Linden
2017-01-25MAINT-7082: Remove waiting loop in frame when textures queued for download ↵Rider Linden
in alternate thread. With debug spam for observation.
2016-12-22MAINT-7024 Release notes page was requested prior to proxy initialization.andreykproductengine
2016-12-05Merged in lindenlab/viewer-releaseAndreyL ProductEngine
DRTVWR-412 Bento (avatar skeleton extensions)
2016-11-21Merged in Ansariel/storm-2141AndreyL ProductEngine
2016-11-16mergeBrad Payne (Vir Linden)
2016-11-14STORM-2141: Fix various inventory floater related issues:Ansariel
* Opening new inventory via Control-Shift-I shortcut uses legacy and potentinally dangerous code path * Closing new inventory windows don't release memory * During shutdown legacy and inoperable code for inventory window cleanup is called * Remove old and unused inventory legacy code
2016-11-08Backed out changeset: 2a56972b1571AndreyL ProductEngine
Reverting MAINT-6259
2016-11-08Backed out changeset: 27782e83386bAndreyL ProductEngine
Reverting MAINT-6793
2016-11-14MAINT-6920 More information in About Second Life floaterandreykproductengine
2016-11-14Merged in lindenlab/viewer-cleanupAndreyL ProductEngine
2016-10-18mergeBrad Payne (Vir Linden)
2016-10-18MAINT-6793 Rigged mesh sometimes full of holesandreykproductengine
2016-10-11MAINT-5232: Merge up to VLC viewer from viewer-releaseNat Goodspeed
2016-10-10Merged in lindenlab/viewer-releaseAndreyL ProductEngine
2016-09-20mergeBrad Payne (Vir Linden)
2016-09-16MergeRider Linden
2016-09-16MergeRider Linden
2016-09-16Automated merge with ssh://bitbucket.org/lindenlab/viewer-releaseNat Goodspeed
2016-09-15MAINT-5232: Normalize LLSingleton subclasses.Nat Goodspeed
A shocking number of LLSingleton subclasses had public constructors -- and in several instances, were being explicitly instantiated independently of the LLSingleton machinery. This breaks the new LLSingleton dependency-tracking machinery. It seems only fair that if you say you want an LLSingleton, there should only be ONE INSTANCE! Introduce LLSINGLETON() and LLSINGLETON_EMPTY_CTOR() macros. These handle the friend class LLSingleton<whatevah>; and explicitly declare a private nullary constructor. To try to enforce the LLSINGLETON() convention, introduce a new pure virtual LLSingleton method you_must_use_LLSINGLETON_macro() which is, as you might suspect, defined by the macro. If you declare an LLSingleton subclass without using LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() in the class body, you can't instantiate the subclass for lack of a you_must_use_LLSINGLETON_macro() implementation -- which will hopefully remind the coder. Trawl through ALL LLSingleton subclass definitions, sprinkling in LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() as appropriate. Remove all explicit constructor declarations, public or private, along with relevant 'friend class LLSingleton<myself>' declarations. Where destructors are declared, move them into private section as well. Where the constructor was inline but nontrivial, move out of class body. Fix several LLSingleton abuses revealed by making ctors/dtors private: LLGlobalEconomy was both an LLSingleton and the base class for LLRegionEconomy, a non-LLSingleton. (Therefore every LLRegionEconomy instance contained another instance of the LLGlobalEconomy "singleton.") Extract LLBaseEconomy; LLGlobalEconomy is now a trivial subclass of that. LLRegionEconomy, as you might suspect, now derives from LLBaseEconomy. LLToolGrab, an LLSingleton, was also explicitly instantiated by LLToolCompGun's constructor. Extract LLToolGrabBase, explicitly instantiated, with trivial subclass LLToolGrab, the LLSingleton instance. (WARNING: LLToolGrabBase methods have an unnerving tendency to go after LLToolGrab::getInstance(). I DO NOT KNOW what should be the relationship between the instance in LLToolCompGun and the LLToolGrab singleton instance.) LLGridManager declared a variant constructor accepting (const std::string&), with the comment: // initialize with an explicity grid file for testing. As there is no evidence of this being called from anywhere, delete it. LLChicletBar's constructor accepted an optional (const LLSD&). As the LLSD parameter wasn't used, and as there is no evidence of it being passed from anywhere, delete the parameter. LLViewerWindow::shutdownViews() was checking LLNavigationBar:: instanceExists(), then deleting its getInstance() pointer -- leaving a dangling LLSingleton instance pointer, a land mine if any subsequent code should attempt to reference it. Use deleteSingleton() instead. ~LLAppViewer() was calling LLViewerEventRecorder::instance() and then explicitly calling ~LLViewerEventRecorder() on that instance -- leaving the LLSingleton instance pointer pointing to an allocated-but-destroyed instance. Use deleteSingleton() instead.
2016-09-15Merged in lindenlab/viewer-releaseAndreyL ProductEngine
2016-09-14MergeRider Linden
2016-08-31MAINT-5232: Add LLSingletonBase::cleanupAll() and deleteAll() callsNat Goodspeed
near the end of LLAppViewer::cleanup() so every LLSingleton class that hasn't already been explicitly cleaned up gets a chance to perform its own cleanup.
2016-08-31MAINT-5232: LLMetricPerformanceTesterBasic::cleanClass->cleanupClassNat Goodspeed
for consistency with everything else, so we can use SUBSYSTEM_CLEANUP() macro to call it.
2016-08-30MAINT-5232: Change getIfExists() call to instanceExists().Nat Goodspeed
LLSingleton::getIfExists() has been eliminated. The only remaining way to detect whether a given LLSingleton has been instantiated is to call instanceExists(). But the relevant cleanup code should be refactored to cleanupSingleton() anyway, which would make this specific call moot.
2016-08-30Automated merge with ssh://bitbucket.org/lindenlab/viewer-releaseNat Goodspeed
2016-08-29Automated merge with ssh://bitbucket.org/lindenlab/viewer-vlcNat Goodspeed
2016-08-26MAINT-5011: Add top-level exception handlers in LLAppViewer::frame().Nat Goodspeed
2016-08-20MAINT-6662 Don't show release notes on first loginAndreyL ProductEngine
2016-08-20MAINT-6663 [Win LibVLC] test video buttons still appearing in searchAndreyL ProductEngine
2016-08-17Automated merge with ssh://bitbucket.org/lindenlab/viewer-releaseNat Goodspeed
2016-08-17MAINT-5011: Use LLTHROW() instead of plain BOOST_THROW_EXCEPTION().Nat Goodspeed
A level of preprocessor indirection lets us later change the implementation if desired.
2016-08-16Merge VOB with 4.0.8-releasepavelkproductengine
2016-08-15merge from viewer-releaseBrad Payne (Vir Linden)
2016-08-11merge changes for 4.0.7-releaseOz Linden
2016-08-15MAINT-6634 fixed stringandreykproductengine
2016-08-15MAINT-6634 "My graphics driver is out of date" was listed 3 times in Alertsandreykproductengine
2016-07-19MAINT-5011: Introduce LLException base class for viewer exceptions.Nat Goodspeed
This also introduces LLContinueError for exceptions which should interrupt some part of viewer processing (e.g. the current coroutine) but should attempt to let the viewer session proceed. Derive all existing viewer exception classes from LLException rather than from std::runtime_error or std::logic_error. Use BOOST_THROW_EXCEPTION() rather than plain 'throw' to enrich the thrown exception with source file, line number and containing function.
2016-07-19MAINT-6259 rigged items' LOD should be size dependent, not only avatar dependentandreykproductengine
2016-07-13MAINT-5011: Throw an actual exception in Force Software Exception.Nat Goodspeed
http://en.cppreference.com/w/cpp/language/throw says of the plain throw syntax: "This form is only allowed when an exception is presently being handled (it calls std::terminate if used otherwise)." On advice from Oz, replace plain 'throw;' with throwing a std::runtime_error.
2016-07-13MAINT-6493 SL Viewer does not respect the Windows 10 display setting size sliderpavelkproductengine
2016-07-18Backed out changeset: a1a0a055e892andreykproductengine
2016-07-04MAINT-6259 rigged items' LOD should be size dependent, not only avatar dependentandreykproductengine
2016-06-30DRTVWR-418: Unify control flow through LLAppViewer across platforms.Nat Goodspeed
The LLApp API used to consist of init(), mainLoop(), cleanup() methods. This makes sense -- but on Mac that structure was being subverted. The method called mainLoop() was in fact being called once per frame. There was initialization code in the method, which (on Mac) needed to be skipped with an already-initialized bool. There was a 'while' loop which (on Mac) needed to be turned into an 'if' instead so the method would return after every frame. Rename LLApp::mainLoop() to frame(). Propagate through subclasses LLAppViewer and LLCrashLogger. Document the fact that frame() returns true to mean "done." (This was always the case, but had to be inferred from the code.) Rename the Mac Objective-C function mainLoop to oneFrame. Rename the C++ free function it calls from runMainLoop() to pumpMainLoop(). Add comments to llappdelegate-objc.mm explaining (inferred) control flow. Change the Linux viewer main() and the Windows viewer WINMAIN() from a single LLAppViewer::mainLoop() call to repeatedly call frame() until it returns true. Move initialization code from the top of LLAppViewer::frame() to the init() method, where it more properly belongs. Remove corresponding mMainLoopInitialized flag (and all references) from LLAppViewer. Remove 'while (! LLApp::isExiting())' (or on Mac, 'if (! LLApp::isExiting())') from LLAppViewer::frame() -- thus unindenting the whole body of the 'while' and causing many lines of apparent change. (Apologies to reviewers.) There are four LLApp states: APP_STATUS_RUNNING, APP_STATUS_QUITTING, APP_STATUS_STOPPED and APP_STATUS_ERROR. Change LLAppViewer::frame() return value from (isExiting()) (QUITTING or ERROR) to (! isRunning()). I do not know under what circumstances the state might transition to STOPPED during a frame() call, but I'm quite sure that if it does, we don't want to call frame() again. We only want a subsequent call if the state is RUNNING. Also rename mainLoop() method in LLCrashLogger subclasses LLCrashLoggerWindows, LLCrashLoggerMac, LLCrashLoggerLinux. Of course it's completely up to the frame() method whether to yield control; none of those in fact do. Honor protocol by returning true (frame() is done), even though each one's main() caller ignores the return value. In fact LLCrashLoggerWindows::mainLoop() wasn't using the return protocol correctly anyway, returning wParam or 0 or 1 -- possibly because the return protocol was never explicitly documented. It should always return true: "I'm done, don't call me again."
2016-06-13MAINT-6366 - diagnostics related to animation asset downloadsBrad Payne (Vir Linden)
2016-06-02MAINT-5194 Visual Outfit browserpavelkproductengine
Made refactoring of LLFloaterOutfitSnapshot and LLFloaterSnapshot