Directional Input Delays with latest PBR-Capable Viewers

[canny[bot]]

Repro: (Courtesy of Atomic Infinity. Thank you!)

1. Go to an empty region and let everything load - I used an empty sandbox.
2. Put the following script in a prim, then add/wear it on your avatar.
3. Press and hold the Left arrow key down for 10 seconds.
4. At the end of 10 seconds, the script will report how many control events triggered in those 10 secs.
5. You can then let go the arrow key, and repeat the test to verify the results.
6. Log out and try the same in a different viewer.

integer count;
default
{
control(key id, integer levels, integer edges)
{
integer start = levels & edges;
integer end = ~levels & edges;
if (start & CONTROL_ROT_LEFT)
{
count = 0;
llSetTimerEvent(10.0);
llOwnerSay("Timer started.\nHold key on for 10 seconds.");
}
if (end & CONTROL_ROT_LEFT)
{
llSetTimerEvent(0.0);
}
count += 1;
}
timer()
{
llSetTimerEvent(0.0);
llOwnerSay("Timer stopped.\nControl events count per 10sec : "+(string)count);
}
attach(key ID)
{
if (ID != NULL_KEY)
{
llSetTimerEvent(0.0);
count = 0;
llRequestPermissions(ID, PERMISSION_TAKE_CONTROLS);
}
}
run_time_permissions(integer perm)
{
if (perm & PERMISSION_TAKE_CONTROLS)
{
 llTakeControls(CONTROL_ROT_LEFT, TRUE, FALSE);
}
}
}

Dan Linden's results on Win10/NVIDIA GeForce GTX 1080: 7.1.8.9375512768 - Materials Featurettes - Control events count per 10sec : 271 7.1.7.8974243247 - Maintenance-X - Control events count per 10sec : 271 7.1.6.8745209917 - Maintenance-YZ - Control events count per 10sec : 271 7.1.5.8443591509 - Maintenance-W - Control events count per 10sec : 443 7.1.4.8149792635 - GLTF PBR Maint 2 - Control events count per 10sec : 439 7.1.3.7878383867 Emoji - Control events count per 10sec : 429

Observed: Starting in Release 7.1.6.8632452945 - Maintenance-YZ, the response is 271.

Expected: The number of control events per second should be higher, as it was in Maintenance-W and earlier viewers.

---

Original report follows:

Directional inputs are noticably delayed and/or inconsistent in PBR viewers compared to non-PBR viewers, said delays being most noticeable when operating vehicles. Delays in inputs can result in key-presses that are longer than intended, or in some cases may result in no input being registered at all (the latter most notable again while operating a vehicle).

To test for the bug, it is recommended that the tester be proficient with vehicle operation, namely on the grounds of consistency, and that the tests be carried out on a closed circuit (and optionally one with a timing system).

Recommended testing locations:

LC Racing Circuits: http://maps.secondlife.com/secondlife/YToub%20System/95/65/3931

Racers Island: http://maps.secondlife.com/secondlife/Racers%20Island/6/7/385

Free race-ready vehicles ideal for these tests are available at the landing points.

The bug has so far been tested and discovered in the official LL viewer, Firestorm viewer, and Alchemy viewer. It is yet to be known if it persists elsewhere, but is highly suspected of being the case.

(This issue currently threatens the existence of racing communities as it has become vastly more difficult to safely control their vehicles)

https://secondlife.canny.io/admin/board/bug-reports/p/directional-input-delays-with-latest-pbr-capable-viewers

[canny[bot]]

This issue has been linked to a Canny post: Directional Input Delays with latest PBR-Capable Viewers :tada:

[beqjanus]

This was introduced by LL Commit https://github.com/FirestormViewer/phoenix-firestorm/commit/a67dde1f16c144247cff0b765201e64f8f8e75c2 - SL-20783 Fix excessive control messages.

One option is to simply revert the change, but that does allow for floods esp when (as is not entirely uncommon) people seeking high-performance, low-jitter rates deliberately feature limit the rendering. The timer-based approached used introduces a sampling issue, subject to Nyquist errors and given the high volatility of the viewer FPS (consider mirrors updating every 4th frame) experimentation suggests you need a mac update rate of 125 to reliably attain 45fps (the region event frequency) with an fps average of 70 and variance of +/-40. This will vary wildly of course from person to person, and scene to scene. 125 seems safe, but not much of a cap.

A better solution would probably be to extract the event loop from the rendering and ensure that the region gets updates independent of the volatility of rendering.

[AndrewMeadows]

This issue interacts with the GameControl viewer so I'm looking into it.