This is necessary for opensim mega regions that can have up to 16 long
poll connections for a single service, while upping the maximum number
of connections per service just for that is clearly nonsense.
I also changed that long poll connections do not "use" the "Other"
capability type (which shows that the debug info in the HTTP debug
console for the Other capability type turns grey when it only has event
poll connections). As a result additional connections become available
for textures, mesh and the inventory (the other capability types) on
opensim, which has all types on the same service, because now Other
does no longer constantly reserves a full share of the available
connections. This makes the actual number of connections used for
textures and mesh a lot more like it is on Second Life.
Turns out that the only responders that want to get the redirect
status codes themselves are the ones that already had a
redirect_status_ok() exception.
Merged cleanly:
indra/llkeyframewalkmotion.cpp - 36e6946c96 - worked around a bug in Aurora walking motion
indra/llrender/llimagegl.cpp - fa8e1f033b - An llerrs here becomes an llwarns, to avoid bothering the user with non power of two dimensioned images
indra/newview/llmanip.cpp, indra/newview/llmanipscale.cpp - "Changed hardcoded 256 constants and such to width functions" - a50f0008b2
indra/newview/llpatchvertexarray.cpp - fa8e1f033b - Support patches of non power of two width
indra/newview/llworldmap.h - conflict
Conflicts:
indra/llmessage/patch_code.cpp - My version cleaned up a bit of code duplication, so this was applied, within the new tags
indra/llmessage/patch_code.h - b_large_patch in decode_patch_header defaults to false, indra/newview/llcloud.cpp patch removed.
indra/llmessage/patch_dct.h - false positive
indra/newview/llagent.cpp - false positive
indra/newview/llfloaterregioninfo.cpp - nonsl wacky textures support meets the refactor.
indra/newview/llfloaterworldmap.cpp - false positive
indra/newview/llglsandbox.cpp - false positive
indra/newview/llnetmap.cpp - small changes for type consistency brought into FS' patch, nothing important; also adds change to LLNetMap:draw removing getRegionWidthInMeters to keep using the constant REGION_WIDTH
indra/newview/llpanelobject.cpp - Get the region width of the object we're editing for maximum pasted x/y coords
indra/newview/llstartup.cpp - [Fixes old issues] My old patch did not fully use first_sim_size_x here, this has been fixed. The unused first_sim_size_y has been removed.
indra/newview/llsurface.cpp - rebuildWater isn't used, removed for now. Styling conflicts otherwise.
indra/newview/llsurfacepatch.cpp - remove FS patch that comments out code that isn't even in the modern source; cleaned up a mess of tags with more clear explanation, perhaps it can be expanded upon though. Some styling conflicts.
indra/newview/llviewermessage.cpp - Fix the problem? setRegionWidth by number.
indra/newview/llviewerobject.cpp - false positive
indra/newview/llviewerparcelmgr.cpp - just styling conflicts
indra/newview/llviewerparcelmgr.h - false positive
indra/newview/llviewerparceloverlay.cpp - false positive
indra/newview/llviewerparceloverlay.h - false positive
indra/newview/llviewerregion.cpp - cleaned up LLViewerRegion::getCompositionXY patches, they're more in the way than they're worth; removed DispatchOpenRegionSettings capability mention for now, it's not related to variable regions. Also remove rebuildWater, it's not used right now.
indra/newview/llvowater.cpp - false positive
indra/newview/llwind.cpp - remove decode_patch_header patches for false, since we have a default; otherwise false positive.
indra/newview/llworld.*
- [Fixes old issues] Remove setRegionWidth by LLMessageSystem as the messages used are not always the same, the by number one remains of course.
- Retained separation of connecting neighbors through the old method when the width is 256
- updateLimits() would never have been merged in, we have an entirely different grid manager, therefore it's removed.
- Fix the stupidity passed on over the years wherein a static constant variable would hold the same value as the first call to setLandFarClip..
indra/newview/llworldmap.cpp - 36e6946c96 Aurora map workaround stuffs, parts removed; rework of LLWorldMap::simInfoFromHandle
indra/newview/llworldmap.h - Cleaned up organization, avoid making members public, and fixed tagging
Some opensim servers might not have a reverse DNS, which causes
a stall of up to 5 seconds for each call. This means that
every time you up the parcel music stream (or any other media)
the viewer would freeze six times 5 seconds.. 30 seconds.
With this patch it only freeze once ;) (when you enter a region).
It already did that before (too), but after that opening the
parcel media doesn't freeze the viewer at all anymore.
Apparently LLViewerMediaImpl::navigateInternal could be called with
an empty url. That lead to a curl request with an empty url, which
failed because that leads to an empty 'service' string, which is
not allowed.
Patched the code to ignore empty media urls and hardened AICurl
to deal with any remaining cases.
I need to parse the debug output of libcurl for this, and choose
to not do that for a Release build - at which point it makes little
sense to even do it for a Debug build, since also the Alpha release
are 'Release'. Even though it would probably have no impact on FPS,
there would be like two persons looking at that number and understanding
it.
The automatic adjustment sets the connect time to 3 seconds, which might
be a bit on the short side sometimes.
Also remove the HACK and use CurlTimeoutConnect again.
The default is still 10 seconds, but is overridden to be 30 for mesh
now (which needs a reconnect for every mesh, since LL does not support
connection reuse for mesh). Note that I never saw any successful
connect under 8 seconds while I had the connect time out at 30:
Over 8 seconds is a sure fail (except for mesh, where in rare cases
there were connect times of 15 seconds (never 14 or 16).
On quiet servers, the connect time is normally sub-second. This is
the bulk of connections for my own SL use.
XMLRPCResponder is used to login, which is a HTTP 1.0 server
that doesn't support reuse of connections.
It's cleaner to close connections from our side too.
This changes,
0x7fffdcf93700 CURLIO 0x7fffcd86db40 * Connection #0 to host login.agni.lindenlab.com left intact
into
0x7fffdcf93700 CURLIO 0x7fffcd8b0bd0 * Closing connection #0
This make more sense when comparing the threshold against 2 times the
maximum allowed total connections.
As a result, textures won't stall when there are around 128 mesh
requests queued.
Keep track of which capability types are used and in use
at the moment for each service.
Update the http debug console to only show services
that have at least one capability type marked as used (this resets upon
restart of the debug console) and show previously used but currently
unused capability types in grey.
Update CapabilityType::mConcurrentConnections based on usage of the
capability type (CT): Each currently in-use CT gets an (approximate)
equal portion of the available number of connections, currently
unused CTs get 1 connection for future use, so that requests can and
will be added to them if they occur. If a CT is currently not in use
but was used before then it's connection (but at most one connection)
is kept in reserve. For example, if there are 8 connections available
and a service served textures and mesh in the past, but currently
there are no texture downloads, then mesh get at most 7 connections,
so that at all times there is a connection available for textures.
When one texture is added, both get 4 connections.
Prepares for throttling number of connections per capability type.
The value is current left at AIPerService::mConcurrectConnections,
so not having an effect yet.
This fires so little that it isn't worth anymore to look into it
(the only problem resulting from this is a wrong timeout on one
of the http requests); and therefore no longer makes sense to
have it triggered in alpha builds at all, since those do not
produce enough debug output to understand what caused it in the
first place.
Condenses the three moderation responders to one.
Adds Speakers settings.
Uses dedicated timer class to track speakers on the list
Adds temporary getSpeakerManager() function to LLFloaterIMPanel to play the role of LLIMModel::getSpeakerManager
Migrate a bunch of classes out of llvoiceclient.* and into new llvoicevivox.*
Update most of these to match their counterparts
Introduce VoiceFonts support (voice morphing, floater still to come)
Support for a bunch of v3 voice settings.
Move volume settings management from LLMutelist into LLSpeakerVolumeStorage
Support for Avaline mutes (WIP)
Adds voice section to LLAgent
Moved llfloatervoicedevicesettings to llpanelvoicedevicesettings, v3's voice device panel design is more intuitive.
This splits the AIPerService queue up into four queues: one for each
"capability type". On Second Life that doesn't make a difference in
itself for textures because the texture service only serves one
capability type: textures. Other services however can serve two types,
while on Avination - that currently only has one services for everything
- this really makes a difference because that single service now has
four queues.
More importantly however is that the administration of how many requests
are in the "pipeline" (from approving that a new HTTP request may be
added for given service, till curl finished it) is now per capability
type (or service/capabitity type pair actually). This means downloads of
a certain capability type (textures, inventory, mesh, other) will no
longer stall because unapproved requests cluttered the queue for a given
service.
Moreover, before when a request did finished, it would only look for a
new request in the queue of the service that just finished. This simple
algorithm worked when there were no 'PerSerice' objects, and only one
'Curl' queue: because if anything was queued that that was because there
were running requests, and when one of those running requests finished
it made sense to see if one of those queued requests could be added now.
However, after adding multiple queues, one for each service, it could
happen that service A had queued requests while only requests from
service B were actually running: only requests of B would ever finish
and the requests of A would be queued forever.
With this patch the algorithm is to look alternating first in the
texture request queue and then in the inventory request queue - or vice
versa, and if there are none of those, look for a request of a different
type. If also that cannot be found, look for a request in another
service. This is still not optimal and subject to change.
