User Experience Interest Group/Transcripts/2009-12-03

Topic

User Experience Interest Group Discussion for December 03, 2009.

Topic: Reducing Perceived Lag.

Summary

No summary is yet available for this meeting. Please edit this page to add one.

Links

• SVC-3895 - Rezzing Mono scripted object cripples sim FPS
• SNOW-375 - Detached Communicator: Chat/IM/Contacts windows "thinking outside the box" in a separate process/plugin

Transcript

[15:31]	Jacek Antonelli:	Okay then, let's start.
[15:32]	Jacek Antonelli:	Today we're talking about reducing perceived lag -- that is, making the viewer experience feel responsive even if there's lag going on
[15:33]	Jacek Antonelli:	As a counterpart to actually making it less laggy, heh.
[15:33]	Armin Weatherwax:	i have the feeling i lag less since i replaced libhasnothingtodowithlag.so by an heavyly opimized version ;)
[15:33]	Charlette Proto:	how about anything to make sure chat is in order?
[15:33]	Charlette Proto:	haha Garn
[15:34]	Jacek Antonelli:	Hal Klaxon suggested this topic a couple weeks ago. He was specifically interested in making movement feel less laggy
[15:34]	Garn Conover tilts head
[15:34]	Jacek Antonelli:	Hi Aimee and Morgaine, you're just in time
[15:34]	Morgaine Dinova waves quietly
[15:34]	Aimee Trescothick:	lo
[15:34]	Jacek Antonelli:	We're talking about reducing perceived lag in the viewer
[15:34]	Garn Conover woofs softly @ Morgaine and Aimee
[15:34]	Jacek Antonelli:	At the moment, regarding movement
[15:34]	Govern Overland:	Well as this isn't a 3DFPS or such, would it not make more sense for the client to be authoritive over their coordinates instead of the server? that way rubberbanding would more or less done with.
[15:34]	Charlette Proto:	not sure if it makes sense to cueeue chat and delay it even more, but the lines could be made chronological
[15:34]	Morgaine Dinova:	Garn: woof! :-)
[15:35]	Geneko Nemeth:	Whoa! Lots of people today! So what did I miss?
[15:35]	Jacek Antonelli:	We're just starting, Gen
[15:35]	Geneko Nemeth:	What?!
[15:35]	Geneko Nemeth:	Then what was happening in the past 35 minutes?
[15:35]	Geneko Nemeth:	I demand a transcript! <g>
[15:35]	Jacek Antonelli:	I was rather late, heh. Sorry about that.
[15:35]	Morgaine Dinova:	Sorry about lateness, a very interesting legal question came up at Merov's
[15:35]	Armin Weatherwax:	we waited for you Geneko
[15:35]	Charlette Proto:	good point Govern, but we would all see different workds
[15:36]	Geneko Nemeth:	Ehh... *blushes*
[15:36]	Charlette Proto:	legal question mhmm
[15:36]	Jacek Antonelli:	Govern: That's true, if the viewer told the server where the agent was, instead of the server telling the viewer, then your own movement could appear less laggy
[15:36]	Jacek Antonelli:	Although it would complicate things, especially with regard to physics and collision
[15:37]	Morgaine Dinova:	Server always has to be authoritative, else the potential for abuse is enormous
[15:37]	Charlette Proto:	some peeps say phys could be client side
[15:37]	Govern Overland:	Charlette/Jacek: would cause a different kind of lag, like you might not notice I've left if you're lagging. or might end up seeing me move a few seconds later but all in all everything would/should catch up.
[15:38]	Govern Overland:	What kind of abuse are you talking about.. I come from doom and quake where the server has to be authoritive for fairness but this isn't that kind of world.
[15:38]	Morgaine Dinova:	Physics can certainly be assisted client side (and it should be, as clients have the power) ... but it should never be authoritative.
[15:38]	Charlette Proto:	yeah - world out of wack for various users Govern
[15:38]	Morgaine Dinova:	Govern: this isn't one specific kind of world. It's whatever people want to use it for.
[15:39]	Charlette Proto:	maybe it would lag less (I think) if phys went clientside
[15:39]	Thickbrick Sleaford:	quake-like games demonstrate that having non-authoritative client side physics helps a lot.
[15:39]	Charlette Proto:	especially on the good machines
[15:41]	Charlette Proto:	but quake was like single user game connected to the server's world
[15:41]	Charlette Proto:	I never tried multiuser quake, but don't remember anyone complaining too much
[15:42]	Jacek Antonelli:	Hrm. I think for practical reasons, the authoritative position/physics stuff will have to stay on the server side. But there could be ways to use client-side physics to improve the feel of it.
[15:42]	Thickbrick Sleaford:	they would if the servers was taking breaks to synchronously serialize mono assemblies frmo time to time.
[15:42]	Thickbrick Sleaford:	(they would complain)
[15:43]	Govern Overland:	The way I see it, to solve or give the illusion of a less laggy world. the rubber banding and or not being able to move is the issue. that from what I understhand is the sim's hardward and or connection not having the ability to provide enough processing time or bandwidth to all the people within the sim. or shares sims.. to give the illusion of less lag, the slowwalkin/rubber banding needs to be addressed in some way.
[15:43]	Charlette Proto:	guess a smoother world less suitable to FPS like tasks would be better than lag
[15:43]	Govern Overland:	shared*
[15:43]	Jacek Antonelli:	One of the issues currently is that the viewer doesn't tell the server "I'm moving forward starting at time X", it essentially relays your input (arrow key presses) to the server, then the server tells you what happened.
[15:44]	Jacek Antonelli:	So you don't start moving until the server receives your input. Which in laggy situations, could lead to a noticeable delay between when you press the key and when you start moving.
[15:45]	Charlette Proto:	ah OK Jacek, I thought it dealt wit posidion/direction changes not at higher level than arrow keys
[15:45]	Geneko Nemeth:	Actually it does.
[15:45]	Geneko Nemeth:	For example, mouse steering, which changes your direction without being constrained by speed of keyboard rotation.
[15:46]	Geneko Nemeth:	But that doesn't change the fact you don't start moving until the server gets your input.
[15:46]	Charlette Proto:	sending keystrokes seems the wrong (buggy/latent) way of doing it
[15:47]	Charlette Proto:	so if mouse uses messages instead of raw data, maybe one could test which format is best
[15:47]	Geneko Nemeth:	Not to mention that it's rather limited. For example, if the protocol is only limited to key presses (which it is not, expect for practical purposes), I can't do a "click here on the ground to move to that direction" aka Japanese/Korean MMO styled input scheme.
[15:48]	Jacek Antonelli:	If the viewer told the server *when* you started to move forward, it might be possible to forward-project to the current time to see where you are now. Then the viewer could start you walking forward immediately while it waited for feedback from the server. It'd be really messy, though.
[15:49]	Govern Overland:	Hopefully once we all get our new Petabyte harddrives we'll have enough space to store the entire asset database on our computers, easing the overhead on LL servers and thus making the world less laggy?
[15:49]	Jacek Antonelli:	heh
[15:49]	Geneko Nemeth:	Not if you live in China (which I don't)...
[15:49]	Charlette Proto:	smoothing of position data would help (?)
[15:49]	Thickbrick Sleaford:	i think it was done that way to avoid dealing in the viewer with all the special cases where a key doesn't mean movement (sitting, move lock, etc.)
[15:49]	Charlette Proto:	Mao Tse Tung never lagged
[15:49]	Jacek Antonelli:	Let's just hope for quantum entanglement based network connections, so we can transfer data faster than the speed of light.
[15:50]	Geneko Nemeth:	Charlette: I think "rubberbanding" is kind of a primitive version of smoothing position data.
[15:50]	Charlette Proto:	haha what is the avs get entangled on top of a poseball
[15:50]	Charlette Proto:	haha some smoothing Gen
[15:51]	Morgaine Dinova:	1 TB drives only cost $50 right now. You could store all the assets and terrain info you ever come across in regular travels comfortably on that, if only the viewer cache weren't a pile of crap.
[15:51]	Geneko Nemeth:	It's true! Have you noticed that you don't just immediately snap back but there's a rubber band effect?
[15:51]	Thickbrick Sleaford:	Charlette: by smoothing you mean averaging between the authoritative and current position?
[15:51]	Jacek Antonelli:	Personally, I don't think there is much that can be practically done to make movement more responsive in laggy situations. But there are other aspects of the viewer experience that could be improved. Let's talk about those for a while, shall we?
[15:51]	Charlette Proto:	think you are right Gen - the av keeps walking once started, but pails to stop till it gets 'corrected' inworld
[15:52]	Morgaine Dinova:	It's just F'ing unbelieveable that we're having to reload out own home zones a dozen times each day every time we port back home.
[15:52]	Govern Overland:	Are you shitting me the asset database/textures etc are under a terabyte? that can't be.. O.o
[15:52]	Morgaine Dinova:	Govern: no no, only one person's typical travels
[15:52]	Govern Overland:	excuse my french...
[15:52]	Geneko Nemeth:	And apparantly there's no way to know when server slows down, so rubber banding can come quite unexpected to client...
[15:52]	Charlette Proto:	somoothing in a way of having averaged positions based on data and predictive next step
[15:52]	Morgaine Dinova:	The entire SL asset store is around 400 TB, but you don't visit a significant part of it.
[15:53]	Geneko Nemeth:	There's something else I want to talk about w/r/t/ interpolating velocity.
[15:53]	Jacek Antonelli:	Geneko: True. For example, when the sim is suffering from time dilation, the viewer would have to figure out how fast you would be moving, or it would rubber band even more than it does now.
[15:53]	Geneko Nemeth:	Err, I was talking about now...
[15:53]	Armin Weatherwax:	what about having a proxy which pretends the physics to the client and does the actual movement when the sever is responsive?
[15:54]	Geneko Nemeth:	Armin: I thought we already do have one of these.
[15:54]	Geneko Nemeth:	Inside the viewer.
[15:54]	Govern Overland:	Well I could store 0.5%.. on my just installed NAS..! and I thought it was big O.o --- anyway sorry back to the subject.
[15:54]	Geneko Nemeth:	You can try turning Network->Interpolate Objects off in the Advanced menu.
[15:54]	Jacek Antonelli:	Let's hear Geneko's comment about interpolating velocity, then move on. (Was that it, Gen?)
[15:55]	Geneko Nemeth:	Anyway, yeah, w/r/t/interpolating velocity and crossing region boundaries...
[15:55]	Morgaine Dinova:	The viewer already does speculative movement based on heurists and interpolation, otherwise your flying would be appallingly jerky owing to Internet RTT randomness.
[15:55]	Thickbrick Sleaford:	that's just dead reckoning, no friction/collisions
[15:55]	Geneko Nemeth:	1- If you ride a vehicle, the vehicle freezes at boundary but the viewer continue to interpolate for it.
[15:56]	Geneko Nemeth:	2- if you don't connect soon enough your avatar could be interpolated off-world while your agent is still frozen at region boundary.
[15:56]	Geneko Nemeth:	Can be quite disconcerting.
[15:56]	Charlette Proto:	I never tried simcrossings without velocity interpolate - worth a go to see what it is like
[15:57]	Geneko Nemeth:	Server interpolated movement if you cross boundary - but only if not riding vehicle.
[15:57]	Jacek Antonelli:	Oof, yeah. I remember that from my sailing days. If you had a bad sim crossing, your viewer could send you spinning off into outer space, heh.
[15:57]	Thickbrick Sleaford:	eeeep, 8000 ms ping sim
[15:57]	Geneko Nemeth:	s/interpolated/interpolates/
[15:57]	Charlette Proto:	could it be done better? like built in latency one gets to adjust till if feels good (or viewer optimimised at all times)
[15:57]	Garn Conover:	i got stuck in outer space cuz i tried to TP with phantom AV on lol
[15:58]	Charlette Proto:	the way you fx glitchy sound - add latency
[15:58]	Morgaine Dinova:	Imprudence 1.2.1 really rocks, btw, well done gals and guys :-)
[15:58]	Geneko Nemeth:	Yeah, that I want to talk about too.
[15:58]	Charlette Proto:	haha more lag - but well measured kind
[15:58]	Thickbrick Sleaford:	anybody knwos what "ping interpolate object positions" does?
[15:59]	Geneko Nemeth:	idk... but I think it's an alternative to velocity interpolating
[16:00]	Jacek Antonelli:	Let's switch over to another aspect of reducing perceived lag -- chat lag
[16:00]	Geneko Nemeth:	Apparantly IRC doesn't have server echoing your chat message.
[16:00]	Thickbrick Sleaford:	nothing you can do about server taking a nap
[16:00]	Charlette Proto:	yeah Jacek, chat out of oreder?
[16:01]	Geneko Nemeth:	Or more likely... UDP packets traveling on different routes, one of them happening to have lots of traffic on there
[16:01]	Govern Overland:	Once upon a time. even if you were disconnected from your sim or the sim was locked up/crashing chatting in groups still worked reliably. I notice these days thats not the case, even often being booted out of chat group sessions because of lag.
[16:01]	Jacek Antonelli:	Yeah. Chat out of order is one of the biggest problems with chat lag.
[16:01]	Charlette Proto:	could it be queued up when the lag is bad
[16:01]	Dzonatas Sol:	There have been proxies to make chat appear in-client when the server is actually jabber based.
[16:02]	Jacek Antonelli:	Right now, I think chat is displayed in the order it arrived. I'm pretty sure they used to queue it, but that could lead to chat *never* showing up in bad lag
[16:02]	Jacek Antonelli:	That is, if you always waited for chat A to arrive before showing chat B and C. If chat A gets lost on the way...
[16:03]	Charlette Proto:	when chat lag hits it would be better to be more behind than out of wack the way it is
[16:03]	Dzonatas Sol:	hard to fix once it gets out of order
[16:03]	Jacek Antonelli:	I suppose you could have a slight delay (e.g. wait up to 5 seconds for A to arrive)
[16:03]	Jacek Antonelli:	Rather than a permanent wait
[16:03]	Dzonatas Sol:	thought about that
[16:03]	Dzonatas Sol:	probably would be noticable
[16:04]	Jacek Antonelli:	Another possible solution would be to retroactively insert earlier chat if they arrived. But that could be really, really confusing.
[16:04]	Boroondas Gupte:	one would have to decouple the "when" and the "where" of chat display. When B and C arrive, display them raight away, once A follows, insert it before B.
[16:04]	Dzonatas Sol:	jabber uses tcp, i think, so it wouldn't be so out of order
[16:04]	Charlette Proto:	what about laggy connection on one group member lagging the whole group IM???
[16:04]	Geneko Nemeth:	Jacek: Not to mention requiring modification of protocol.
[16:04]	Charlette Proto:	one could turn on a 56k modem and stuff up a group
[16:05]	Charlette Proto:	intentional lag griefing wow
[16:05]	Charlette Proto:	lets all fall back in time together
[16:05]	Dzonatas Sol:	groups could have non-ll servers, but the client would need to know how to connect. that is kinda the discussion going on Aw groupies right now =)
[16:05]	Thickbrick Sleaford:	i think delaying lines until previous lines arrive can work if the mac delay is dependant on the current ping-sim value
[16:06]	Thickbrick Sleaford:	*max delay
[16:06]	Charlette Proto:	clientside latency fix would be the only way to do it
[16:06]	Geneko Nemeth:	That assumes the server receives chat messages in order.
[16:07]	Geneko Nemeth:	Well, I guess one can try.
[16:07]	Thickbrick Sleaford:	the server's order is "the order"
[16:07]	Geneko Nemeth:	Not necessarily.
[16:07]	Morgaine Dinova:	Out of order :P
[16:08]	Charlette Proto:	the laggy chat would be fixed (optionally) by introducing ping time based latency and a queue
[16:08]	Boroondas Gupte:	Thickbrick, for chat from different residents, yes. But what if text of a silnle one already arrives out of order at the server?
[16:08]	Charlette Proto:	wow I just go hit with chat lag myself
[16:08]	Boroondas Gupte:	*single
[16:08]	Geneko Nemeth:	Boroondas: Then there's nothing that can be done at the client side witht he current protocols.
[16:09]	Jacek Antonelli:	In theory, the message protocol could include a timestamp of when it was sent, which would allow messages to be ordered either on the server or the client.
[16:09]	Jacek Antonelli:	You'd have to trust the client's timestamp, though.
[16:10]	Charlette Proto:	the messages are timestamped and could be spat out from a queue at some delayed time - all sounds like more lag though
[16:10]	Thickbrick Sleaford:	I think sender -> server out of oder problems are pretty rare
[16:10]	Geneko Nemeth:	There's no way to know that for sure though.
[16:10]	Jacek Antonelli:	People could cheat at quiz games by having their client say they said the answer 5 seconds before they did *grins*
[16:10]	Thickbrick Sleaford:	heh
[16:10]	Boroondas Gupte:	:-è
[16:10]	Boroondas Gupte:	*:-P
[16:10]	Charlette Proto:	one could test it by sanding clientside timestamps alone
[16:10]	Charlette Proto:	and see where it kicks in
[16:12]	Jacek Antonelli:	There's also the issue of scripts that listen to chat. You'd have to delay chat to them too, to wait for things to come in order.
[16:12]	Charlette Proto:	even sending atomic clock timestamps
[16:12]	Charlette Proto:	listening scripts are less critical most of the time
[16:12]	Geneko Nemeth:	Then you might have time drift, clock adjustment, leap seconds, ... this is muddy waters.
[16:12]	Geneko Nemeth:	Wow, my chat just got lagged.
[16:13]	Jacek Antonelli:	Yeah, this sim is a great place to talk about chat lag, heh.
[16:13]	Charlette Proto:	really wish people used channels for stupid messages like AO ON
[16:14]	Charlette Proto:	I'm sure the LSL listen lags all chat
[16:15]	Jacek Antonelli:	Charlette: A small bit, yes. Not as much as normal network conditions do, though.
[16:15]	Charlette Proto:	Local Chat based control shouldn't be used
[16:16]	Charlette Proto:	besides the fact that I don't care whose AO was turned on or freebie radar started, it all is a load
[16:16]	Jacek Antonelli:	Hrm. The best (IMO) solution I've heard so far would be to have a short waiting period in the client, which varies based on network condition, to allow out of order chat to come in.
[16:17]	Thickbrick Sleaford:	considering the sad state of http://jira.secondlife.com/browse/SVC-3895 all these small loads don't really matter.
[16:17]	Charlette Proto:	Jacek; yeah I agree
[16:17]	Thickbrick Sleaford:	jacek: sounds good
[16:18]	Geneko Nemeth:	I'd rather have the client reorder chat afterwards. Don't like artificial delays.
[16:18]	Thickbrick Sleaford:	if the delay is long enough to noticeable then it's already failed
[16:18]	Charlette Proto:	chat buffer wouldn't use much resource at all
[16:18]	Jacek Antonelli:	You wouldn't be able to tell the difference between the delay and the server's lag, heh
[16:19]	Geneko Nemeth:	But the server isn't lagging all the time.
[16:19]	Jacek Antonelli:	Right. That's why the delay period varies with the network status. "Good weather" = short delay. "Bad weather" = long delay.
[16:19]	Geneko Nemeth:	So it is based on packets dropped?
[16:20]	Jacek Antonelli:	That might be part of it. Also ping time and stats sent from the server.
[16:20]	Geneko Nemeth:	Don't think it's a good idea to base it on ping time. It would be adding another level of delay over network and rendering.
[16:21]	Charlette Proto:	that is a point Gen, network and rendering are interleaved
[16:22]	Thickbrick Sleaford:	anyway, ChatFromSimulator doesn't seem to have a timestamp
[16:22]	Geneko Nemeth:	Is there a timestamp/serial# in the message protocol?
[16:23]	Charlette Proto:	is the timestamp purely clientside (eg the IMs have viewing timestamp instead of sent)???
[16:23]	Boroondas Gupte:	I think so.
[16:24]	Charlette Proto:	I have a JIRA on that and nobody seems to suggest solutions to the useless IM timestamps
[16:24]	Jacek Antonelli:	Yeah, I think so to. Offline IMs have their own extra timestamp in the message text, though.
[16:25]	Charlette Proto:	even emailed IMs are a mess
[16:25]	Charlette Proto:	time for the big messaging overhaul
[16:26]	Geneko Nemeth:	Poof.
[16:26]	Charlette Proto:	LL seem to have hacked everything together without care for what 'real' systems work like
[16:26]	Geneko Nemeth:	So I've heard of this rumor that routers prefer TCP, is that true?
[16:27]	Charlette Proto:	bit like kiddies at home who never learnt the wheel was invented a long time ago
[16:27]	Jacek Antonelli:	How do you mean "prefer" ?
[16:27]	Geneko Nemeth:	Giving priority to, dropping packets from UDP, etc...
[16:27]	Charlette Proto:	that sounds right Gen
[16:27]	Jacek Antonelli:	Ah. I dunno. I wouldn't be surprised if they did, though.
[16:28]	Thickbrick Sleaford:	TCP is supposed to be reliable, where UDP isn't so some @#$@!#% ISPs throtle UDP
[16:28]	Boroondas Gupte:	When they have to drop packages, a lot will drop UDP ones first. "Priority", I don't think so ... first come, first routed.
[16:28]	Charlette Proto:	UPD has no data integrity - so I'd drop if first
[16:28]	Thickbrick Sleaford can't use skype in the afternoon
[16:29]	Geneko Nemeth:	Like some @*($&@*(#! ISPs intercept NXDOMAIN responses and send you a pretty page full of laggy ads instead...
[16:29]	Charlette Proto:	scared to use Skype after dark
[16:29]	Geneko Nemeth:	Worse if said interception is done on the country-level gateway. (It's been done.)
[16:29]	Jacek Antonelli:	Ick.
[16:30]	Morgaine Dinova:	Must ... use ... Skype --- otherwise you're cheating the NSA out of their rightful snoop input.
[16:31]	Thickbrick Sleaford:	heh
[16:31]	Charlette Proto:	NSA are listening on our chat now (hello NSA dude)
[16:31]	Geneko Nemeth:	Bleh, I think we just got way off topic.
[16:31]	Jacek Antonelli:	Okay, I think let's wrap it up for this week. Any final comments?
[16:31]	Geneko Nemeth:	Yeah, laggy sound.
[16:31]	Geneko Nemeth:	Especially under Linux.
[16:32]	Thickbrick Sleaford:	yes!
[16:32]	Boroondas Gupte:	http://bash.org/?88575
[16:32]	Charlette Proto:	regulated server load sharing (hoggs) would help all lag
[16:32]	Geneko Nemeth:	Where you have OpenAL -> ALSA -> PulseAudio -> ALSA -> 100ms mix buffer -> Hardware...
[16:33]	Charlette Proto:	give each av the same server time
[16:33]	Charlette Proto:	or user tools to measure and police load
[16:33]	Geneko Nemeth:	I like UI sounds, and would rather them be buffered on the sound server, but I don't think OpenAL would let me.
[16:33]	Thickbrick Sleaford:	sound from objects usually lags a lot more than 100ms, even when the sound is suposedly cached already.
[16:34]	Jacek Antonelli:	I guess sound effects from objects get to enjoy all the lag of network events, plus the lag of the sound server. Yay for them
[16:35]	Thickbrick Sleaford:	plus the lag of sequential UDP fetching
[16:35]	Boroondas Gupte:	and decoding to wave
[16:35]	Jacek Antonelli:	Yeah
[16:35]	Jacek Antonelli:	Fun times.
[16:35]	Thickbrick Sleaford:	i.e. if a packet is out of order, the whole fetch stalls.
[16:36]	Jacek Antonelli:	They are using UDP fetches for something where order matters? Whee
[16:36]	Charlette Proto:	I've seen a lot of 'out of order' packets in logs lately
[16:36]	Thickbrick Sleaford:	lol
[16:36]	Thickbrick Sleaford:	same as textures
[16:36]	Geneko Nemeth:	Why should order of asset packets matter?
[16:37]	Thickbrick Sleaford:	I guess textures suffer more, because they need to be decoded a lot during the fetch
[16:37]	Dzonatas Sol:	Oh, we could just send every UDP packet twice in some random order, or maybe thrice. that would help
[16:37]	Dzonatas Sol:	=)
[16:37]	Thickbrick Sleaford:	heh
[16:38]	Jacek Antonelli:	This sim is a great example for lag. I wonder when they last restarted it.
[16:38]	Dzonatas Sol:	there is the old ihave/sendme protocol of uucp that i never heard a complaint about
[16:39]	Thickbrick Sleaford:	probably easier to just reimplement sounds it as an http cap (if that really is a significant lag factor)
[16:40]	Jacek Antonelli:	Some day they'll finish HTTP texture fetching. Then they can use it for other assets as well.
[16:40]	Morgaine Dinova:	Woot, SL over UUCP!
[16:40]	Morgaine Dinova:	:P
[16:40]	Thickbrick Sleaford:	that's probably one of those things where having a viewer_opensim working solution would help saw some lindens to implement it
[16:41]	Thickbrick Sleaford:	(viewer + opensim_
[16:41]	Thickbrick Sleaford:	bleh, I can't type. I blame lag.
[16:41]	Jacek Antonelli:	hehe
[16:41]	Charlette Proto:	lag is an issue of load and open-sim never has production level population loads
[16:42]	Morgaine Dinova:	Opensim's been stress tested to 100 avs recently, which is pretty amazing considering it's alpha.
[16:43]	Charlette Proto:	or anything like the machines/connections to test lag for what I've seen - lag, really bad
[16:43]	Geneko Nemeth:	(But people won't wear 100+ prims in OpenSim...)
[16:43]	Charlette Proto:	try thousends Gen
[16:43]	Geneko Nemeth:	Okay, is there anything else about -perceived- lag?
[16:43]	Charlette Proto:	thousands*
[16:43]	Charlette Proto:	yeah - headspace
[16:44]	Morgaine Dinova:	Imprudence 1.2.1 is rock solid in Opensim under Linux 32-bit btw. I've been using it in the 30+ person OSgrid meetings, it's 100% stable.
[16:44]	Thickbrick Sleaford:	Jacek: how abotu low fps affecting typing?
[16:44]	Thickbrick Sleaford:	(client side fps, that is)
[16:45]	Boroondas Gupte:	yeah, I wouldn't care about 3D FPS, if UI FPS weren't the same.
[16:45]	Geneko Nemeth:	Thinkbrick: It doesn't, except pressing enter to open chat bar initially.
[16:45]	Charlette Proto:	I get 30-40 FPS and lag
[16:45]	Charlette Proto:	like here today
[16:45]	Thickbrick Sleaford:	really low fps makes typing hard(er)
[16:46]	Jacek Antonelli:	Yeah
[16:46]	Charlette Proto:	over 40 FPS and bouts of lag
[16:46]	Jacek Antonelli:	Decoupling input events from rendering FPS would definitely help. As would decoupling UI rendering from world rendering.
[16:46]	Morgaine Dinova:	That's because networking and all input events are handled synchronously in the render loop. One of the biggest problems of the LL viewer.
[16:47]	Morgaine Dinova:	Aye
[16:47]	Geneko Nemeth:	Most games handle it that way.
[16:47]	Thickbrick Sleaford:	i don't see that changin anytime soon
[16:47]	Jacek Antonelli:	It makes my head hurt just thinking about all the work it would take to untangle everything. X(
[16:47]	Geneko Nemeth:	I think there's one that doesn't, which was a rhythem game...
[16:47]	Morgaine Dinova:	This is why when your rendering FPS drops to 1 FPS, your sim ping becomes 1000 ms. They're totally coupled.
[16:47]	Charlette Proto:	all pre multithread machines
[16:47]	Morgaine Dinova:	Bad design
[16:48]	Dzonatas Sol:	synchronous threads avoid the need for locks
[16:48]	Jacek Antonelli:	Easier design.
[16:49]	Charlette Proto:	Second Life™ is a museum of code
[16:49]	Geneko Nemeth:	Even so on the servers, probably.
[16:50]	Thickbrick Sleaford:	dzonatas: can your multi-window patch be used to composit the windows back into SL window?
[16:50]	Charlette Proto:	a cracked coffee bean under a key is causing me some lag now hehe
[16:50]	Dzonatas Sol:	yes, but that is in the Studio version
[16:50]	Boroondas Gupte:	Charlette, don't put such stuff under your keys.
[16:51]	Jacek Antonelli:	Yeah, keyboards don't eat coffee beans, silly. You're supposed to pour the coffee drink right on it.
[16:51]	Morgaine Dinova:	Dzon, what was your Jira link again?
[16:51]	Geneko Nemeth:	Jacek: But it does!
[16:51]	Boroondas Gupte:	https://jira.secondlife.com/browse/SNOW-375
[16:51]	Morgaine Dinova:	Thanks Bor
[16:51]	Charlette Proto:	zen is the only way to fix perceived lag - just chill out
[16:51]	Boroondas Gupte:	yw
[16:52]	Dzonatas Sol:	ty
[16:52]	Thickbrick Sleaford:	Dzonatas: I guess you still can't escape the fact that window is used for 3d. If you composit into it you end up losing any (output) latency advantage
[16:52]	Thickbrick Sleaford:	?
[16:52]	Jacek Antonelli:	That's one way of reducing perceived lag... shoot the user with a tranquilizer dart when it starts to get laggy, so they won't perceive it.
[16:53]	Boroondas Gupte:	hmmm ... needs new hardware, though.
[16:53]	Charlette Proto:	is there a patch to render floaters outside of the main viewer 3D window?
[16:53]	Dzonatas Sol:	the hardware can composite layers, but there is no standard between linux and windows to do it by hardware
[16:53]	Charlette Proto:	or reverse
[16:53]	Boroondas Gupte meant the tranquilizer
[16:53]	Dzonatas Sol:	that's what monovida does
[16:54]	Dzonatas Sol:	i started to move the map outside in its own windows, but then SL code has OpenGL written in a way that prevents shared resources. OpenGL can be multi-window multi-thread, but SL doesn't allow it
[16:54]	Charlette Proto:	wow, we like to talk about rendering out of 3D, nice
[16:54]	Geneko Nemeth:	Aww
[16:55]	Charlette Proto:	shit
[16:55]	Charlette Proto:	poo^
[16:55]	Boroondas Gupte:	?
[16:55]	Dzonatas Sol:	so MonoVida uses Gtk for all windows, and embeds the viewer in GtkGL
[16:55]	Geneko Nemeth:	How hard is it to re-write it?
[16:55]	Morgaine Dinova:	Dzon: what is LL doing that prevents multi-window GL?
[16:56]	Dzonatas Sol:	I have gotten the map to work in another window, but it is so buggy because of how SL setup their pointers that assume a single instance
[16:56]	Morgaine Dinova:	Ah, so just not coded to expect it, kk
[16:56]	Charlette Proto:	like the rest of the rocket grade code
[16:57]	Geneko Nemeth:	It doesn't HAVE to be multi-thread to be multi-window...
[16:57]	Dzonatas Sol:	right
[16:59]	Geneko Nemeth:	So "single instance" means single instance of OpenGL context?
[17:00]	Dzonatas Sol:	yes
[17:01]	Charlette Proto:	are we though?
[17:01]	Geneko Nemeth:	Whoo, I'm short. ^^
[17:02]	lufpleh Obstreperous:	thx all ㋡
[17:02]	Jacek Antonelli:	Yes, let's adjourn
[17:02]	Morgaine Dinova:	Good chat, thanks all
[17:02]	Jacek Antonelli:	Take care everyone, see you next week!
[17:02]	Morgaine Dinova:	Tnx Jacek, tc :-)