| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# indra/llcommon/llsdutil.cpp
# indra/newview/VIEWER_VERSION.txt
# indra/newview/lldrawpoolalpha.cpp
# indra/newview/lldrawpoolwater.cpp
|
|
|
|
# Conflicts:
# autobuild.xml
# doc/contributions.txt
# indra/cmake/GLOD.cmake
# indra/llcommon/tests/llprocess_test.cpp
# indra/newview/VIEWER_VERSION.txt
# indra/newview/lldrawpoolavatar.cpp
# indra/newview/llfloatermodelpreview.cpp
# indra/newview/llmodelpreview.cpp
# indra/newview/llviewertexturelist.cpp
# indra/newview/llvovolume.cpp
# indra/newview/viewer_manifest.py
|
|
Mac/Intel
|
|
down loading issues, fix sync issue in single threaded mode in media textures, restore LL_IMAGEGL_THREAD_CHECK functionality
|
|
querying for available video memory.
|
|
LLImageGL thread to update, fix AMD sync issue on ImageGL thread and install debug callbacks on LLImageGL thread when debug gl enabled.
|
|
This reverts commit 40fe5277e1390c975d9a3184ff8fc46d69dfb450, reversing
changes made to af830e5fc5840194be95140f644a27011b9b7e06.
|
|
This reverts commit dcf8f695367a1bcc9c495ea93a89927dd83802af, reversing
changes made to 594910a8408f67f1af7c66d5a4dfde3626669245.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/app_settings/key_bindings.xml
# indra/newview/llappviewer.cpp
# indra/newview/llkeyconflict.cpp
|
|
|
|
|
|
# Conflicts:
# indra/media_plugins/cef/media_plugin_cef.cpp - setOnLoadEndCallback
# indra/newview/llviewerassetstorage.cpp - mAssetCoroCount
|
|
|
|
# Conflicts:
# indra/newview/VIEWER_VERSION.txt
|
|
# Conflicts:
# doc/contributions.txt
|
|
# Conflicts:
# autobuild.xml
# indra/newview/installers/windows/lang_pl.nsi
# indra/newview/llfloaterpreference.cpp
# indra/newview/llinventorymodel.cpp
|
|
|
|
|
|
|
|
|
|
but by storing the OpenID cookie when it arrives then injecting it forcefully into each new media instance, it appears that the 'not logged in' problem is solved - at least in my testing, 20+ times logging in without a cache and profiles, dashboard etc. were all logged in - QA will confirm. The full solution involves providing a separate cache for each media instance and tightening up the CEF cookie calling code - that is a large project and this is sufficient for now
|
|
internal repo to public one.
|
|
|
|
screw ups)
|
|
|
|
|
|
|
|
Remade code to use getCursorFromString
|
|
|
|
Looks like viewer is missing some certs in the bundle or doesn't know how to handle web page's certs. For now disabling verification to not block DRTVWR-516. Verification was originally turned on in DRTVWR-516's SL-13927
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
|
|
# Conflicts:
# autobuild.xml
# indra/newview/llimprocessing.cpp
|
|
|
|
following release of D512.
|
|
|
|
|
|
This changeset is meant to exemplify how to convert a "namespace" class whose
methods are static -- and whose data are module-static -- to an LLSingleton.
LLVersionInfo has no initClass() or cleanupClass() methods, but the general
idea is the same.
* Derive the class from LLSingleton<T>:
class LLSomeSingleton: public LLSingleton<LLSomeSingleton> { ... };
* Add LLSINGLETON(LLSomeSingleton); in the private section of the class. This
usage implies a separate LLSomeSingleton::LLSomeSingleton() definition, as
described in indra/llcommon/llsingleton.h.
* Move module-scope data in the .cpp file to non-static class members. Change
any sVariableName to mVariableName to avoid being outright misleading.
* Make static class methods non-static. Remove '//static' comments from method
definitions as needed.
* For LLVersionInfo specifically, the 'const std::string&' return type was
replaced with 'std::string'. Returning a reference to a static or a member,
const or otherwise, is an anti-pattern: the interface constrains the
implementation, prohibiting possibly later returning a temporary (an
expression).
* For LLVersionInfo specifically, 'const S32' return type was replaced with
simple 'S32'. 'const' is just noise in that usage.
* Simple member initialization (e.g. the original initializer expressions for
static variables) can be done with member{ value } initializers (no examples
here though).
* Delete initClass() method.
* LLSingleton's forté is of course lazy initialization. It might work to
simply delete any calls to initClass(). But if there are side effects that
must happen at that moment, replace LLSomeSingleton::initClass() with
(void)LLSomeSingleton::instance();
* Most initClass() initialization can be done in the constructor, as would
normally be the case.
* Initialization that might cause a circular LLSingleton reference should be
moved to initSingleton(). Override 'void initSingleton();' should be private.
* For LLVersionInfo specifically, certain initialization that used to be
lazily performed was made unconditional, due to its low cost.
* For LLVersionInfo specifically, certain initialization involved calling
methods that have become non-static. This was moved to initSingleton()
because, in a constructor body, 'this' does not yet point to the enclosing
class.
* Delete cleanupClass() method.
* There is already a generic LLSingletonBase::deleteAll() call in
LLAppViewer::cleanup(). It might work to let this new LLSingleton be cleaned
up with all the rest. But if there are side effects that must happen at that
moment, replace LLSomeSingleton::cleanupClass() with
LLSomeSingleton::deleteSingleton(). That said, much of the benefit of
converting to LLSingleton is deleteAll()'s guarantee that cross-LLSingleton
dependencies will be properly honored: we're trying to migrate the code base
away from the present fragile manual cleanup sequence.
* Most cleanupClass() cleanup can be done in the destructor, as would normally
be the case.
* Cleanup that might throw an exception should be moved to cleanupSingleton().
Override 'void cleanupSingleton();' should be private.
* Within LLSomeSingleton methods, remove any existing
LLSomeSingleton::methodName() qualification: simple methodName() is better.
* In the rest of the code base, convert most LLSomeSingleton::methodName()
references to LLSomeSingleton::instance().methodName(). (Prefer instance() to
getInstance() because a reference does not admit the possibility of NULL.)
* Of course, LLSomeSingleton::ENUM_VALUE can remain unchanged.
In general, for many successive references to an LLSingleton instance, it
can be useful to capture the instance() as in:
auto& versionInfo{LLVersionInfo::instance()};
// ... versionInfo.getVersion() ...
We did not do that here only to simplify the code review.
The STRINGIZE(expression) macro encapsulates:
std::ostringstream out;
out << expression;
return out.str();
We used that in a couple places.
For LLVersionInfo specifically, lllogininstance_test.cpp used to dummy out a
couple specific static methods. It's harder to dummy out
LLSingleton::instance() references, so we add the real class to that test.
|
|
|
|
|
|
performance (previously 8e228364f324)
|
