Age | Commit message (Collapse) | Author |
|
# Conflicts:
# indra/llrender/llgl.cpp
# indra/newview/lloutfitslist.cpp
|
|
* Enable CEF browser for Linux
* Disable the update for Linux, we don't have that one right now
* Update build_linux.yaml
We need libpulse-dev for volume_catcher Linux
* Add linux_volum_catcher* files
* Enable OpenAL for Linux-ReleaseOS
* Linux: Update OpenAL
* Update SDL2
* Add libsndio-dev to the dependencies.
* Update CEF to an official LL version
* Remove dupe of emoji_shortcodes
* Reording autobuild does because it can and wants to
* Linux: Disable NDOF for the time being. After updating the ndof 3P needs to be rebuilt and we do not have a fresh one from LL yet.
Forcefully undefine LIB_NDOF, it gets defined in the build variables no matter if it is safe to define.
* Remove wrestling with mutliarch and LIBGL_DRIVERS_PATH
* Remove tcmalloc snippet, tcmalloc is a very faint bad dream of the past
* Putting out a warning this viewer ran on a x64 arch and then suggesting to install 32 bit compat packages makes no sense at all
* CEF resources need to be in lib
* It;'s okay to warn about missing plugins
* Linux: CEF keyboard handling
* Remove old gstreamer 0.10 implementation
* Linux DSO loading always had been very peculiar due to macro magic.
At least now it is peculiar shared magic with only one implementation.
* Remove -fPIC. We get that one from LL_BUILD
* /proc/cpuinfo is not reliable to detrmine the max CPU clock. Try to determine this by reading "/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq".
Only if this fails go back to /proc/cpuinfo
* Cleanup
* Cleanup common linker and compiler flags, make it more obvious which flags are for which OS/compiler
* Switch to correct plugin file
* Install libpulse-dev for volume catcher.
* And the runner needs libsndio-dev as well.
* check for runner.os=='linux'. matrix.os is the full name of the image (limux-large).
|
|
* compile flag cleanup for linux
* rollback indra/llcommon/llprofiler.h
* use 3p fltk package
* fix build gcc 13 (dangling-pointer)
|
|
Co-authored-by: AiraYumi <aira.youme@airanyumi.net>
|
|
|
|
|
|
# Conflicts:
# .github/workflows/build.yaml
|
|
Closing window correctly caused a significant amount of logout freezes
with no known reproes. Temporarily returning to old behavior were thread
was killes without closing window and will reenable in later maints to
hopefully get a scenario or at least more data of what is causing the
freeze.
|
|
Under debug LL_ERRS will show a message as well, but release won't show
anything and will quit silently so show a notification when applicable.
|
|
|
|
|
|
|
|
Note that crash happened when setting LLProgressView::setMessage
|
|
|
|
|
|
|
|
|
|
|
|
|
|
UIImgInvisibleUUID doesn't exist
Default normal for material is 'null'
|
|
1. After window closes viewer still takes some time to shut down, so
added splash screen to not confuse users (and to see if something gets
stuck)
2. Having two identical mWindowHandle caused confusion for me, so I
split them. It looks like there might have been issues with thread being
stuck because thread's handle wasn't cleaned up.
3. Made region clean mCacheMap immediately instead of spending time
making copies on shutdown
|
|
|
|
a preset...' option of the 'Preferences' floater
|
|
coroutines).
|
|
# Conflicts:
# indra/newview/fonts/DejaVu-license.txt
# indra/newview/fonts/DejaVuSans-Bold.ttf
# indra/newview/fonts/DejaVuSans-BoldOblique.ttf
# indra/newview/fonts/DejaVuSans-Oblique.ttf
# indra/newview/fonts/DejaVuSans.ttf
# indra/newview/fonts/DejaVuSansMono.ttf
|
|
# Conflicts:
# indra/newview/llspatialpartition.cpp
|
|
|
|
|
|
# Conflicts:
# indra/llrender/llgl.cpp
# indra/llrender/llvertexbuffer.cpp
# indra/llui/llflatlistview.cpp
# indra/newview/lldrawpoolground.cpp
# indra/newview/llspatialpartition.cpp
# indra/newview/lltexturefetch.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llviewertexture.cpp
# indra/newview/llvosky.cpp
# indra/newview/skins/default/xui/en/floater_preferences_graphics_advanced.xml
# indra/newview/skins/default/xui/en/floater_stats.xml
# indra/newview/skins/default/xui/en/floater_texture_fetch_debugger.xml
# indra/newview/skins/default/xui/en/notifications.xml
# indra/newview/skins/default/xui/en/panel_performance_preferences.xml
|
|
# Conflicts:
# indra/llcommon/CMakeLists.txt
# indra/newview/llspatialpartition.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llvoavatar.cpp
|
|
by making it thread_local.
|
|
|
|
|
|
|
|
Now that we're building with C++17, we can use Class Template Argument
Deduction to infer the type passed to the constructor of the 'narrow' class.
We no longer require a narrow_holder class with a narrow() factory function.
|
|
With GitHub viewer builds, every few weeks we've seen test failures when
ll_frand() returns exactly 1.0. This is a problem for a function that's
supposed to return [0.0 .. 1.0).
Monty suggests that the problem is likely to be conversion of F32 to F64 to
pass to fmod(), and then truncation of fmod()'s F64 result back to F32. Moved
the clamping code to each size-specific ll_internal_random specialization.
Monty also noted that a stateful static random number engine isn't
thread-safe. Added a mutex lock.
|
|
using for DRTVWR-559
|
|
ensure inventory skeleton loading doesn't block the message system from processing packets.
|
|
On a Windows CI host, we got the dreaded rc 3221225725 aka c00000fd aka stack
overflow.
|
|
The test was coded to push (what's intended to be) the third entry with
timestamp (now + 200ms), then (what's intended to be) the second entry with
timestamp (now + 100ms).
The trouble is that it was re-querying "now" each time. On a slow CI host, the
clock might have advanced by more than 100ms between the first push and the
second -- meaning that the second push would actually have a _later_
timestamp, and thus, even with the queue sorting properly, fail the test's
order validation.
Capture the timestamp once, then add both time deltas to the same time point
to get the relative order right regardless of elapsed real time.
|
|
We define a specialization of LLSDParam<const char*> to support passing an
LLSD object to a const char* function parameter. Needless to remark, passing
object.asString().c_str() would be Bad: destroying the temporary std::string
returned by asString() would immediately invalidate the pointer returned by
its c_str(). But when you pass LLSDParam<const char*>(object) as the
parameter, that specialization itself stores the std::string so the c_str()
pointer remains valid as long as the LLSDParam object does.
Then there's LLSDParam<LLSD>, used when we don't have the parameter type
available to select the LLSDParam specialization. LLSDParam<LLSD> defines a
templated conversion operator T() that constructs an LLSDParam<T> to provide
the actual parameter value. So far, so good.
The trouble was with the implementation of LLSDParam<LLSD>: it constructed a
_temporary_ LLSDParam<T>, implicitly called its operator T() and immediately
destroyed it. Destroying LLSDParam<const char*> destroyed its stored string,
thus invalidating the c_str() pointer before the target function was entered.
Instead, make LLSDParam<LLSD>::operator T() capture each LLSDParam<T> it
constructs, extending its lifespan to the lifespan of the LLSDParam<LLSD>
instance. For this, derive each LLSDParam specialization from LLSDParamBase, a
trivial base class that simply establishes the virtual destructor. We can then
capture any specialization as a pointer to LLSDParamBase.
Also restore LazyEventAPI tests on Mac.
|
|
They do work fine on clang... unblocking the rest of the team during diagnosis.
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
|
|
# Conflicts:
# autobuild.xml
# indra/llcommon/tests/llleap_test.cpp
# indra/newview/viewer_manifest.py
|
|
clang has gotten smart enough to recognize an inline attempt to store to
address zero. Fool it by storing to an address passed as a parameter, and pass
nullptr from a different source file.
|
|
The header file documents that no llrand function should ever return a value
equal to the passed extent, so the one test in llrand_test.cpp that checked
less than or equal to the high end of the range was anomalous.
But changing that to an exclusive range means that we no longer need separate
exclusive range and inclusive range functions. Replace
ensure_in_range_using(), ensure_in_exc_range() and ensure_in_inc_range() with
a grand unified (simplified) ensure_in_range() function.
|
|
|
|
This reverts commit edf0874e0656c6f512df50ee52236209531ca329.
Reverted since it causes a significant uptick in shutdown freezes.
Can't repro those freezes, will seek an alternate solution.
|