llSetRegionPos teleporter problems

[LeafIllusion]

My teleporter script using llSetRegionPos seems to have slowed way down lately.  It still works very well for very short teleports, under 50m.  But for longer distances it seems to hang, often the viewer displays 0,0,0 as location for several seconds.  The script eventually moves the avatar more or less to the desired location.  I was testing today in one of the premium sandboxes and this "momentary hang" happens about 80% of the time when teleporting over 100m distance.  (My destination coordinates were within the same sim.)  It also seems like the llSetRegionPos function is slower to execute, with the avatar often appearing to sit on the teleporter for a second or two.  Again, this slowdown only happens when moving longer distances.  Changing my viewers draw distance did seem to reduce the problem a little.  Also the problem occured with both the default viewer and Firestorm.  I did not notice these problems when I created the script and tested it right after llSetRegionPos was released.  Wondering if anyone else has noticed recent slowing problems with llSetRegionPos scripts or found a cure for it? 

[Rolig Loon]

I haven't noticed a serious problem with it myself, but I may not have been paying close enough attention either. Most of my own sit teleporters are not moving people more than 1000m or so.  I know that Qwalyphi Karpov complained in this forum less than a month ago that he was having trouble with hitting an accurate target location with llSetRegionPos. You might compare notes with him.

[LeafIllusion]

Further testing indicates there is a strong relation to the draw distance set in the viewer's graphics options.  With draw distance set at 300m the successful completion of a 200m teleport without stopping at 0,0,0 was over 80% of the attempts. So does this indicate the viewer is waiting for information to draw the new location?  Is there any cure for this, or just a price to pay for a long teleport?

Other odd things I noted in the 20 test runs using a simpler script than my earlier tests used.  With the draw distance set at 100m, on about 1/3 of the teleports the avatar went to 0,0,0 before eventually going to the destination.  On another 1/3 the teleporter worked quickly and reasonably accurately.  On the last 1/3 my avatar started walking briefly before teleporting and walked a short distance after arriving at the destination.  One time after sucessfully completing the teleport to the destination, the avatar turned and walked by itself all the way across the sim back to the teleporter!

[Jenni Darkwatch]

Unfortunately that does indeed coincide with my own observations. llSetRegionPos has some odd artifacts. The TP to <0,0,0> is one. TPing an object across sim borders often results in a "ghost" left behind for people looking at the object.

[Dora Gustafson]

Like Rolig I never had the kind of problems described in the OP
I used llSetRegionPos in my teleporters since it's release and they go above 1000m as often as anywhere else

I would like to know what the problem is though,
if it is related to the way the function is implemented in the the script, possibly.
So here is my code, with which I have no problems

listen(integer channel, string name, key idWriter, string message){    if(llAvatarOnSitTarget() == idWriter)    {        integer listPosition = llListFindList(destinations, llCSV2List( message ) );        if ( listPosition > 0 )        {            vector targetVector = llList2Vector(destinations, listPosition - 1);            vector homeVector = llGetPos();            if (llSetRegionPos(targetVector))            {                llMessageLinked( LINK_THIS, TRUE, "", NULL_KEY);                llSleep( 1.5 );                llUnSit(idWriter);                llSetRegionPos(homeVector);  // teleport back to home            }            else llUnSit(idWriter);        }        else llUnSit(idWriter);    }}

 

It might be interesting to see the code used by those having problems:)

[Nexii Malthus]

I'm not sure how it is these days, but a long time ago, when I created a warpPos-based teleporter for a respawn area in a combat sim, where we needed to use the teleport on a high frequency, I attempted to solve the 0,0,0 location issue and some rendering issues.

The way I solved it on my setup as to slow down the teleporting into 30m chunk steps, just slowed down enough so that the server would have enough server frames to send the new location and then have the teleporter move onto the next chunk. This all happened really fast in 100 - 400ms across a vast distance, but gave some breathing room for clients to catch up so that it didn't impede with the fast action combat that we rely on.

[Qwalyphi Korpov]

The resident who provided the previous content, if any, has replaced it with this generic statement.

[LeafIllusion]

As with Qwalyphi, I've found inserting a 5 second delay averts the going to 0,0,0 problem, but of course, the cure is about as bad as the problem.  

In response to some of the other comments, the going to 0,0,0 issue almost never happens when making a vertical teleport.  I can also easily go 1000m as long as it is vertical.  With a  few very specific exceptions, it only happens when moving horizontally across the sim for longer distances.  For example I have 4 of these teleporters using this script in my SL home and all work well and extremely fast for the short hopes between rooms.  

I did try hopping across a sim diagonally using primarily vertical hops.  I did this by jumping from one corner up to the 4090m level then back down to the opposite corner of the sim at ground level.  When I tried that the 0,0,0 issue occured on the way down.  I have tried inserting various length delays into my script in multiple combinations of places with no success unless the delays exceeded a length of 5 seconds.  But having the avatar implanted on the teleporter in a store directory sign for 5 seconds looks rather silly, so not a good option!  I even tried hopping in 50m jumps across the sim, but also still had the 0,0,0 issue.  It is possible I could create a 2 hop teleport that places the avatar into a hidden room in the sim for the 5 second duration...  if all else fails that is my plan B at this point.

I am starting to wonder if this is this an intentional feature of llSetRegionPos?

So far the only reasonably reliable cure that does not need a delay that I have found is to increase my avatar's draw distance to 300m.  But that isn't helpful for a teleporter that will be used by others as part of a public sim.  It seems to me that this going to 0,0,0 may be a method that the function creators are using to address the time needed by the viewer to load the terrain and texture data for the new destination location.  So perhaps the function is designed to devert the prim to 0,0,0 during this process.  In most cases that would be an oout of the way location for it to sit and wait for the data to load.  

Going to 0,0,0 wouldn't seem to be such a bad thing if it were possible to blank the user's screen or something during the process.  But it is a bit unnerving for an unsuspecting avatar who expects to be teleported to a specific location to find themselves suddenly underwater or underground.  It will give the feeling of an error having happened and they may log out asuming a crash.

I should also not that there is not an issue with llSetRegionPos failing.  Of the 80 or so test teleports I've conducted over the last 3 days, only twice has the teleport failed to complete.  The avatar does make it to a lcoation within a few meters of the destination.  It is just a visually unpleasant process.

Here is the basic code segment I have been using.   Very basic and simple.  The llSleep command has been moved to various location and values in my tests so it can be ignored, this is just where it was on my last test.  Changing it to a 5 second delay at the current position often (not always) does work to stop the 0,0,0 problem.

 

{	vector init_pos = llGetPos();	llSetRegionPos(destination); // use llSetRegionPos function	llSleep(0.2);	llUnSit(user);	llSetRegionPos(init_pos); // use llSetRegionPos function}

 

I really appreciate all the responses an suggestions and comments.  Thank you all!  Keep brainstorming and making suggestions if you will, I will continue to test whatever pops into my feeble brain!

 

 

[LeafIllusion]

Another possible issue with llSetRegionPos:  After the teleporter prim returns to it's original location it sometimes becomes invisible to the avatar who just used it to teleport.  In other words, if you teleport then walk back to the original teleporter location the teleporter prim is not longer visisble.  Sometimes it is just "alpha" and can be sat on  although not visible.  Other times it is not even clickable.   It is visible and useable to other avatars, it is just the one that used it that can't see it.  I have only been able to duplicate this in the Second Life Viewer 3.3.4 and not in the current Firestorm.  Possibly a viewer issue?  I've not been able to find any other mentions of this in the forums.  Thought I would mention it since it showed up numerous times during my llSetRegionPos teleporter tests.  Anyone else noticed this one?

[Dora Gustafson]

I have made some more investigations and thinking about this problem. These are my conclusions so far:

1. The <0,0,0> problem is not caused by the function: llSetRegionPos,
   It is known with the warppos function as well and
   it can be shown easily that the prim is positioned instantly by llSetRegionPos
2. The problem is a "what you see" problem and must be related to the viewer and how the viewer repositions the camera when the location is totally shifted in 'no time'
3. It is claimed that the llSetRegionPos fail the target by several meters.
   I have never seen that and have no ideas about what it can be, but I would like to learn more

To see if the problem is camera related I made a script that places the camera before the teleporting.
This way the camera should be in place when the TP-prim arrives

// Minimized Teleporter script by Dora Gustafson, Studio Dora 2012// using llSetRegionPos()// v1.01 has cam controlvector homeVector;vector targetVector = < 250, 250, 4090 >;string sitter;vector sitPos =  < 0.25, 0.0, 0.6 >; // sit position relative to the primrotation turnOnChair = ZERO_ROTATION; // the amount the avatar is rotated relative to the prim when seatedvector relCamP = <3.0, 0.0, 1.2>; // relative camera to prim positionvector relCamF = < 0.0, 0.0, 0.5 >; // relative focus to prim positionsetCamPos( integer perms, vector focus ){    if ( perms & PERMISSION_CONTROL_CAMERA )    {        vector camPos = focus + (relCamP * llGetRot() * turnOnChair) ;        vector camFocus = focus + relCamF ;        llClearCameraParams();        llSetCameraParams([            CAMERA_ACTIVE, TRUE,            CAMERA_FOCUS, camFocus,            CAMERA_FOCUS_LOCKED, TRUE,            CAMERA_POSITION, camPos,            CAMERA_POSITION_LOCKED, TRUE        ]);    }}resetCamera( integer perms ){    if ( perms & PERMISSION_CONTROL_CAMERA )    {        llClearCameraParams();        llSetCameraParams([ CAMERA_ACTIVE, FALSE ]);    }}default{    state_entry()    {        homeVector = llGetPos();        llSitTarget( sitPos, turnOnChair);        llSetClickAction(CLICK_ACTION_SIT);    }    changed(integer change)    {        if (change & CHANGED_LINK)        {            sitter = llAvatarOnSitTarget();            if ( sitter != NULL_KEY )            {                homeVector = llGetPos();                llRequestPermissions( sitter, PERMISSION_CONTROL_CAMERA );                llSetClickAction(CLICK_ACTION_TOUCH);            }            else            {                resetCamera( llGetPermissions() );                llSetClickAction(CLICK_ACTION_SIT);            }        }    }    run_time_permissions(integer perm)    {        if ( perm & PERMISSION_CONTROL_CAMERA )        {            setCamPos( perm, targetVector);            if (!llSetRegionPos(targetVector))            {                resetCamera( perm );                llOwnerSay("Target is not accessible");            }        }    }    touch_end(integer num)    {        setCamPos( llGetPermissions(), homeVector);        llSetRegionPos(homeVector);    }}

 

 

Note that the script has no llSleep function.
Note: To see the camera being positioned by the script the camera must be in default mode when you sit on the TP-prim(Press the Esc key first)

To me it looks like the visual experience is cleaner with this script but I can't tell if the approach works in places that have the <0,0,0> problem.

I would like to know the result if someone does test it:)

[Qwalyphi Korpov]

The resident who provided the previous content, if any, has replaced it with this generic statement.

[Dora Gustafson]

---

Qwalyphi Korpov wrote:

---

Dora Gustafson wrote:...

1. It is claimed that the
   llSetRegionPos
   fail the target by several meters.
   I have never seen that and have no ideas about what it can be, but I would like to learn more

...

To me it looks like the visual experience is cleaner with this script but I can't tell if the approach works in places that have the <0,0,0> problem....

 

---

In my testing I've discovered that AV arrives at the intended location per the script (llGetObjectDetails.) However, upon UnSitting there is usually a slight additional movement and sometimes a large additional movement.  The large movement problem was removed by increasing the sleep duration before UnSitting.

Locations that have the <0,0,0> problem for me:  LeTigre Sandbox 2, Magnum RC Sandbox 1, Plum (sandbox)

 

---

Is the additional movement one of the TP-prim or of the avatar?

Thank you for the locations, I will soon go and test:)

I have been there and tested in all three sand boxes without seeing any of the named problems:smileysurprised:

 

[LeafIllusion]

I did a rather crude test this morning with a teleporter installed in a substantial private sim build that creates the 0,0,0 problem/issue.  Using my main computer for my avatar and putting a alt on my laptop, I was able to watch the process as viewed by both the teleporting avatar and others not involved in the process.  

As the avatar sat on the teleporter at the origination, the alt saw the avatar attach to and sit on the teleporter.  (This teleporter is part of a store directory sign, so the avatar appeared to be imbedded in the sign.)  There was no consistencey at this point.  Sometimes the avatar would sit imbedded in the sign for a few seconds, sometimes it would just be just a flash and it was gone.  Watcing both screens, the 0,0,0 effect never occured while the avatar was imbedded in the sign, it occured after the avatar had left the original location.  

When viewed from the destination the alt saw the avatar begin to materialize at the destination at the same time the avatar started seeing the 0,0,0 effect.  So when the avatar being teleported is seeing the 0,0,0 location on their screen, everyone else is seeing the avatar already materializing at the destination.

Hope that information helps.

[LeafIllusion]

---

Dora Gustafson wrote:

I would like to know the result if someone does test it:)

---

I tested it as written at Sandbox Verenda (entering destination coordinates that I know have created the 0,0,0 issue), and on 4 tests it worked beautifully each time... quick and smooth, no "0,0,0" issue.

But it doesn't unseat the user from the prim or return the prim.  The last section under "touch_end(integer num)" does not appear to execute.  (Maybe it isn't supposed too?  Am I expecting it to do something you didn't intend?  I confess to just having my nose above water on this and most of your code completely loses me!)   

When I modified it to unseat the user and return the prim, it went the 0,0,0 route like the others.  Now again, I must confess that I can't even follow your scripting, it is so far beyond my beginner abilities!  I have never looked at camera controls and the like.   So my effort to hack that last section to add "llUnSit(sitter)" and get it to execute is probably what is messing it up.

[LeafIllusion]

Just an update to my comment on draw distance.  In testing on an open full-region premium sandbox the draw distance seemed to have a major impact as I previously noted.  However, when testing using the same script in a complex private region with lots of buildings with custom textures, I noticed very little performance improvement from changing the draw distance.   Apparently the complexity of the surroundings has a great deal to do with this...

[Dora Gustafson]

You are right about the script needs a pause before unsitting the avatar.
It needs a pause because the prim is in place long before the avatar and the camera are.
So I thought that if it is possible to check for prim, avatar and camera in place before unsitting, then no pause would be needed.
The script is simple and has not many facilities:

1. Sit and you will TP from where the prim is rezzed to a position hardcoded in the script
2. When all is in place the avatar is unseated and stand on the TP prim(if it is big enough)
3. Sit again and you will TP back and be unseated

// Minimized Teleporter script by Dora Gustafson, Studio Dora 2012// using llSetRegionPos()// v1.01 has cam control// v1.02 with unsit. Use big flat TP-prim where avatar can stand after unsit. A 2.0x2.0x0.1 meter box will do// v1.05 llTarget introduced// v1.07 Check for prim, camara and avatar in positionvector homeVector;vector targetVector = < 56.0, 224.0, 4090 >;string sitter;vector sitPos =  < -0.5, 0.0, 1.5 >; // sit position relative to the primrotation turnOnChair = ZERO_ROTATION; // the amount the avatar is rotated relative to the prim when seatedvector relCamP = < -3.0, 1.0, 2.6>; // relative camera to prim positionvector relCamF = < 0.0, 0.0, 1.9 >; // relative focus to prim positionvector camPos;integer targId;setCamPos( integer perms, vector focus ){    if ( perms & PERMISSION_CONTROL_CAMERA )    {        camPos = focus + (relCamP * llGetRot() * turnOnChair);        vector camFocus = focus + (relCamF * llGetRot() * turnOnChair);        llClearCameraParams();        llSetCameraParams([            CAMERA_ACTIVE, TRUE,            CAMERA_FOCUS, camFocus,            CAMERA_FOCUS_LOCKED, TRUE,            CAMERA_POSITION, camPos,            CAMERA_POSITION_LOCKED, TRUE        ]);    }}resetCamera( integer perms ){    if ( perms & PERMISSION_CONTROL_CAMERA )    {        llClearCameraParams();        llSetCameraParams([ CAMERA_ACTIVE, FALSE ]);    }}default{    state_entry()    {        homeVector = llGetPos();        llSitTarget( sitPos, turnOnChair);        llSetClickAction(CLICK_ACTION_SIT);    }    changed(integer change)    {        if (change & CHANGED_LINK)        {            sitter = llAvatarOnSitTarget();            if ( sitter != NULL_KEY )            {                llRequestPermissions( sitter, PERMISSION_CONTROL_CAMERA | PERMISSION_TRACK_CAMERA );                llSetClickAction(CLICK_ACTION_TOUCH);            }            else            {                resetCamera( llGetPermissions() );                llSetClickAction(CLICK_ACTION_SIT);            }        }    }    run_time_permissions(integer perm)    {        if ( perm & PERMISSION_CONTROL_CAMERA )        {            vector target = homeVector;            if ( llVecDist( llGetPos(), targetVector) > llVecDist( llGetPos(), homeVector)) target = targetVector;            setCamPos( perm, target);            if (llSetRegionPos( target)) targId = llTarget( target, 0.1);            else            {                resetCamera( perm );                llOwnerSay("Target is not accessible");            }        }    }    at_target( integer tnum, vector targetpos, vector ourpos)    {    // This event will fire when the prim is on target and continue to fire untill llTargetRemove is executed    // check for prim, avatar and camera positions. UnSit when all are in place        integer inplace = tnum == targId;        inplace = inplace && llVecDist( llList2Vector( llGetObjectDetails( sitter, [OBJECT_POS]), 0), ourpos + sitPos*llGetRot() ) < 0.5;        if ( llGetPermissions() & PERMISSION_TRACK_CAMERA ) inplace = inplace && llVecDist( llGetCameraPos(), camPos) < 0.5;        if ( inplace )        {            llTargetRemove(targId);            llUnSit( sitter );        }    }    on_rez(integer param) { llResetScript(); }}

 

I find it works well and faster than a script with a "catch all" pause

Out of curiosity I made the same script without cam control.
This script also wait until prim, avatar and camera are in place before UnSit and has no pause

// Minimized Teleporter script by Dora Gustafson, Studio Dora 2012// using llSetRegionPos()// v1.01 has cam control// v1.02 with unsit. Use big flat TP-prim where avatar can stand after unsit. A 2.0x2.0x0.1 meter box will do// v1.03 camera control removed// v1.04 llTarget introduced// v1.06 Check for prim, camara and avatar in positionvector homeVector;vector targetVector = < 56.0, 224.0, 4090 >;string sitter;vector sitPos =  < -0.5, 0.0, 1.5 >; // sit position relative to the primrotation turnOnChair = ZERO_ROTATION; // the amount the avatar is rotated relative to the prim when seatedinteger targId;float camDist;default{    state_entry()    {        homeVector = llGetPos();        llSitTarget( sitPos, turnOnChair);        llSetClickAction(CLICK_ACTION_SIT);    }    changed(integer change)    {        if (change & CHANGED_LINK)        {            sitter = llAvatarOnSitTarget();            if ( sitter != NULL_KEY )            {                llRequestPermissions( sitter, PERMISSION_TRACK_CAMERA );                llSetClickAction(CLICK_ACTION_TOUCH);            }            else llSetClickAction(CLICK_ACTION_SIT);        }    }    run_time_permissions(integer perm)    {        if ( perm & PERMISSION_TRACK_CAMERA )        {            camDist = llVecDist( llGetCameraPos(), llGetPos());            vector target = homeVector;            if ( llVecDist( llGetPos(), targetVector) > llVecDist( llGetPos(), homeVector)) target = targetVector;            if (llSetRegionPos( target)) targId = llTarget( target, 0.1);            else llOwnerSay("Target is not accessible");        }    }    at_target( integer tnum, vector targetpos, vector ourpos)    {    // This event will fire when the prim is on target and continue to fire untill llTargetRemove is executed    // check for prim, avatar and camera positions. UnSit when all are in place        integer inplace = tnum == targId;        inplace = inplace && llVecDist( llList2Vector( llGetObjectDetails( sitter, [OBJECT_POS]), 0), ourpos + sitPos*llGetRot() ) < 0.5;        if ( llGetPermissions() & PERMISSION_TRACK_CAMERA ) inplace = inplace && llVecDist( llGetCameraPos(), llGetPos()) < 2.0*camDist;        if ( inplace )        {            llUnSit( sitter );            llTargetRemove(targId);        }    }    on_rez(integer param) { llResetScript(); }}

 

This script has a very unpredictable behavior, it may UnSit in a short time, a long time or never

[LeafIllusion]

Fantastic script!   Especially the v1.07.  It eliminates the 0,0,0 issue and is fast.  I did notice in my tests that to get the maximum speed the teleporter users need to have Disabled Camera Constraints on their viewers.  That makes sense as it would need to move the camera beyond the 50m default viewer constraint for the distances I was testing.  Nice work!!!

 

[Rolig Loon]

Hmmm... Odd, it doesn't work for me at all, Dora.  The seat and I TP to the target, but the camera position stays at the home position.  The llUnSit is never triggered either.  I have to stand up manually.  I suspect that the at_target event is never being activated.

[Dora Gustafson]

---

LeafIllusion wrote:

Fantastic script!   Especially the v1.07.  It eliminates the 0,0,0 issue and is fast.  I did notice in my tests that to get the maximum speed the teleporter users need to have Disabled Camera Constraints on their viewers.  That makes sense as it would need to move the camera beyond the 50m default viewer constraint for the distances I was testing.  Nice work!!!

---

You did find a serious caveat:smileysurprised:

Thank you for testing!

I would never have found it because I always have Disable Camera Constraints checked

At the moment I have no ideas to overcome that obstacle.

If I find one I will be back

 

[Dora Gustafson]

---

Rolig Loon wrote:

Hmmm... Odd, it doesn't work for me at all, Dora.  The seat and I TP to the target, but the camera position stays at the home position.  The

llUnSit

is never triggered either.  I have to stand up manually.  I suspect that the

at_target

event is never being activated.

---

Thank you for trying it out.

Is the problem that you have Camera Constraints enabled, the problem found by LeafIllusion?

Or is it something else like we use different viewers?

I always use the SL Viewer and if I remember right you never do?

[Rolig Loon]

That's a very good question, Dora.  I tried the version without camera constraints as well as the version with them.  Neither worked.  I haven''t had time yet to analyze the failures or to try modifying the code.  You're right that I never use V3.  Firestorm has worked very well for me since it was first introduced, and I am buoyed by the latest news that Firestorm is the most stable of the viewers in use today.  I doubt that viewer choice is making the difference here, but it's worth studying to be sure.

[Innula Zenovka]

I'm not noticing much difference with disable camera constraints turned off or on, in either Second Life 3.4.0 (264194) Aug 30 2012 14:38:24 (Second Life Beta Viewer) or Catznip R6 (3.2.2) Feb 25 2012 19:57:25 (Catznip Release).   That works well in both cases.

In contrast, it makes a big difference in Firestorm -- then it's far smoother with camera constraints disabled.

 

 

[Nova Convair]

I've added Dora's 1.06 mechanism to my teleporter. (a rezzed transportation prim, teleporter is able to rez multiple transporters to tp a few avatars at once)

Works perfect and smooth under Firestorm and Dolphin so far. With standard camera (esc) or personal camera position and even with camera zoomed far out. (so i could barely see and click the transporter bubble)
In all cases I see myself  at the start position for maybe 2-3 seconds, then zap at target position in an instant. Camera maintains position/focus relative to avatar, so thats perfect for my needs.

I noticed there is a tolerance of 0.1m for the at_target event. Ok for me but maybe too small for those whose at_target never  triggers. For safety i added a SLPPF after the llSetRegionPos to correct errors up to 10m and started a 5.5 second timer to unsit and llDie the transporter prim but that never triggered on my tests.

An Info: If i did a multi teleport (with the standard llSetRegionPos only version) I saw myself and all the others at 0,0,0 for a second. So it's not viewer only since the position of the other avatars is handed over by the server yes?

[Dora Gustafson]

 

Thank you for testing Innula.
I already new the script performs differently for different users in different places and you confirm what I had expected, that it performs differently on different viewers as well. It puzzles me that you have it working on the Firestorm viewer and Rolig has not:smileysurprised:

@Nova: I am very pleased that you make good use of the script and I hope it will not let you down. As you can understand from reading this thread nothing is certain or settled about this way to make a TP or avatar transport.

I must admit I am in unknown territory. I know LSL scripting, but not much about what goes on under the hood, in the viewer.
I made a few more attempts to overcome the camera constraints, but didn't find any improvements to the scripts I made already.

Some of my conclusions are:

1. The function llSetRegionPos works instantly and do what the wiki says it will
2. The problems with this kind of teleporter has to do with the repositioning of avatar and camera
3. For internal region teleporting this is the best we have at the moment
4. llTeleportAgent will be a much better alternative, when it gets promoted from being a llTeleportOwner to  a llTeleportAgent

[Innula Zenovka]

Thinking about it, particularly about why it works one way for Rolig in Firestorm and differently for me, I suspect the user's CPU, GPU and internet connection are likely to be as big a factor as anything else.