Jump to content

Text chat lag/keystroke delay issues on newer CHUI code

Gwyneth Llewelyn

By Gwyneth Llewelyn,
in Second Life Viewer

 Share
You are about to reply to a thread that has been inactive for 3113 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Gwyneth Llewelyn

Gwyneth Llewelyn

Posted
Posted

CHUI, the new user interface for the chat console, is almost one year and a half old. It is considered a "mature" development and as such is available on most of the viewers (both LL's and major TPVs). One big change that CHUI has, in terms of programming, is that the text chat layer is fed into the graphics pipeline differently. It is supposed to work much better that way (keeping, in theory, graphics performance independent and separate from text chatting), and, in fact, that's what happens to a vast majority of users.

Mac users (but apparently many Windows users have reported the same issue), at least under certain conditions, will be unable to use chat. As soon as they enter an area with more than a handful avatars (some report that it happens instantly as soon as a single avatar comes into chat distance), the delay between a keystroke being pressed and the corresponding letter appears on string becomes unbearable — from a few seconds, which is bad enough, to a whole minute, which makes text chatting, for all purposes, impossible.

This is one very hard-to-reproduce bug. Anyone experiencing it will immediately know what I'm talking about; anyone who never had an issue will have no way to reproduce it. It doesn't appear on the logs or on the Fast Timers. Making a movie to show what's happening gives little visual clues about what's going on, unless you use a webcam to show pressing on a key and the delay for the character to appear. Even with that solution, it will still mean that developers and tech support teams will be baffled at what's actually going on.

Obviously it gets worse in low-FPS, multiple-avatar areas, but the problem is not directly connected to those. In many cases, you can have a high-FPS area with just a single avatar, and still experience delays between pressing a key and displaying a character for several seconds. A clue that it is not related to a particular simulator or region is that this affects both IMs and group chats as well. It's quite clear that it's related to the new CHUI code, since CHUI handles all the above in an unified way. Also, using an older viewer on the same area under precisely the same conditions will exhibit no problem whatsoever.

I used to think that this would only affect older Macs with older versions of OS X and using older graphics cards, because these might not support OpenGL fully, and CHUI is very likely using the latest batch of tricks to do its job. My thoughts were that CHUI would find an old card and revert to some software emulation, thus the delay. But apparently it's not the case, since so many brand new Mac (and Windows!) users report exactly the same problem. It's also not related to the size of the chat log on disk (I tried it out with alts without any chat history). What exactly it's related to is difficult to say, since nothing reports an error or a warning. The issue also appears on all regions, at all times (to be honest, I haven't tried it out on OpenSimulator grids... just on Second Life), no matter who is around, what HUDs you're using or wearing, or what viewer you use (so long as the viewer implements LL's CHUI code). It also doesn't depend on the kind of Internet connection. In fact, if it weren't for the fact that non-CHUI viewers have absolutely no problems handling chat-intensive areas, I would say that the problem didn't exist!

My concern is that, since CHUI is now a "mature" feature of SL, and development of non-CHUI viewers are not incorporating the latest improvements, this might mean that a large part of the SL resident population (mostly Mac users, but apparently others as well) will be excluded from text chat. Right now, what I've noticed is that Mac users (probably a majority!) install the latest versions, and, when they notice that this bug is still not fixed, just revert back to a 2012 viewer which has no problems, and patiently wait for another round of viewer releases. This has certainly been my case for the past year or so — I originally reported the bug while testing the beta version of the CHUI viewer, saw that the bug had "propagated" to Firestorm and reported it there as well, and just let things remain that way, unsolved and mostly ignored, while still going back to pre-CHUI viewers.

The latest batch of viewers, however, do really make a difference. Both the LL viewers and the latest Firestorm viewers include amazing developments of the renderer, which, in my very old hardware, achieves almost twice the FPS in the same area. 20-30% improvements are usually dramatic enough, but a 100% improvement is astonishing! Obviously, if you render everything in SL with 100 FPS on a latest-generation graphics card, going up to 120 — or even 200! — will not make a huge difference. But if you're used to single-digit FPS and suddenly get almost 20 FPS on texture-intensive areas, well, then it's obvious that it's time to upgrade your viewer!

This now creates a dilemma. Either you have text chat or you have amazing graphics performance (and rendering of fitted meshes, etc.). Apparently you cannot have both. But the problem is not one of choice: non-CHUI viewers are slowly being discontinued, and it's likely that they will not even be able to connect to SL in the near future. Right now, because there are still some text-based viewers using the non-CHUI API, LL hasn't removed it yet, but this might come in the near future. In the mean time, it's obvious that every new improvement and features will be implemented on CHUI viewers only, so we will be effectively out of the loop, unless, of course, we forfeit text-based chat for our enjoyment in SL.

I'm addressing these forums because I'm desperate :) There is always a chance that someone, somewhere, has found out how to tweak some obscure setting and get rid of this bug — but has not bothered to file a solution either with LL's JIRA (because it has been "closed" for so long until Ebbe opened it again) or Firestorm's (because they don't use it).

Link to comment
Share on other sites
Freya Mokusei

Freya Mokusei

Posted
Posted

A very informative post, thanks Gwyneth.

I've seen this issue reported here and by users in-world. The symptom reports vary - some say there's intense FPS loss or excess lag, others report the delay in typing. Some reports also stated that these delays and losses only started after being logged in for 'a while'. There's some crossover here, and as usual we have to rely on other peoples' description of the problem.

Below are my findings (not proven, please don't read as fact).

---

I did initially hear that turning the CHUI to a 'minimal' view can save some FPS. I have been unable to test that this to be true, and I've since heard that this might be unrelated to the central issue (the typing delay).

My understanding is that Mac users are particularly affected due to Apple's refusal to update their OpenGL implementation (this leaves users with no options). I don't actually know if a Windows/Linux user having a later OpenGL version (reported in Help > About) fixes this issue once it presents since - like you seem to say - my advice has become "Skip on CHUI".

LL seem to have accepted the fact that Apple has stopped progress here. Unfortunately I didn't have access to the JIRA report when it was made (as I didn't report it). I couldn't say whether they'll deploy the fix for this part of the problem.

---

Some links to posts that may fit under this issue:-

Default Viewer Issue: Chat - 14.01.14

MASSIVE FPS drop when using IM chat? - 13.10.23

Genral Lagg in SL - 14.02.04

---

I hope this helps a little bit.

Link to comment
Share on other sites
Gwyneth Llewelyn

Gwyneth Llewelyn

Posted
  • Author
Posted

@Nalates — I had this on JIRA for many months now. Because most of that year the JIRA was closed, I couldn't get more people to test it out and report. Fortunately, the Firestorm JIRA was open, and I could post and comment there — as well as two dozens of others with the same issue. Whirly, who is active on both LL's and Firestorm's JIRA, kept the information flowing.

Alexa Linden closed BUG-4423 as a duplicate of BUG-4121, but I have no access to that. I understand that only "new" bug reports are available to all users. I wished to add the following comment (which I posted on Firestorm's JIRA), because I believe I found a possible workaround; if Alexa or any other super-JIRA-admins are reading this, please add the comment below to BUG-4121 (or give me acces to it so that I might add it myself!). I'm copying the full text here — it's actually a request for doing some extra tests and see if people come to the same conclusion as I did. If yes, this bug might have finally been tracked down, and while it's not likely it will ever be fixed, the workaround seems to give excellent results. Yay for being able to use the newest viewers again!

---

After frying my brains over this, I thought: what could be common across *all* platforms that causes this issue, but is not present on *every* computer (but, rather, just a minority)?

Obviously it could be a certain combination of applications running in the background, but this seemed unlikely: as said, I tested running only Firestorm, and I still had the same problem.

It occurred to me that there is ONE thing which is common across all platforms, but will be different for each user.

Internet Plugins.

These are usually stored in a special folder, from which every browser will load them on demand. On the Mac, they're stored inside ~/Library/Internet Plug-Ins and /System/Library/Internet Plug-Ins. Because all viewers based on LL's code have a built-in browser, they will naturally load those plugins as well. I remember that sometimes I get compatibility issues with them, so maybe, just maybe, they were interfering with the CHUI API...

In my case, I had just three: one for Kitely, one for Picasa, and another for Facebook Video.

I remember a relatively recent announcement that, due to dramatic changes on the Viewer Log-In, Kitely dropped their auto-login plugin, so it's pointless to keep it around. I don't use the Picasa plugin any more. And, well, while I occasionally use Facebook Video, for doing a simple test, I could certainly delete it for a while. The hint that "Kitely dropped the development of their plugin because it interfered with recent viewers" triggered some alarm bells in my head!

So, after making sure those two folders were empty, I logged in and went straight to the Welcome Area in Ahern/Morris, where there are always people chatting. And I'm happy to report that the keystroke delay bug seemed to have gone! There were about a dozen avatars around (it's still early) and I was also furiously IMing someone else. After some 30 minutes it was clear that the bug was not present any longer.

This needs a bit more confirmation! Specially by Windows users! (I don't know where the Internet Plugins are stored under Windows) So delete everything on the Internet Plugin folders and try it out again, and see if it makes a difference. I'm also going to try later on, when the Welcome Area should be crammed full with avatars, and compare the experience.

But so far it sounds really promising!

I'm also going to crosspost this possible solution on every other place where I've reported this bug... we definitely need more people to experiment with it... we might also pinpoint it to a specific Internet Plugin only, and my prime candidate would be Kitely's plugin, as it's highly unlikely that Linden Lab's beta testers would have it installed. But any of the others could make a difference, too. Facebook Video is popular enough, for instance, to be present on many people's computers — but not on the computers of official beta-testers (they would not have time for that!).

Link to comment
Share on other sites
Gwyneth Llewelyn

Gwyneth Llewelyn

Posted
  • Author
Posted

@Freya thanks so much for your help! I followed all those links and apparently the issues are related to same class of problems, namely, some strange incompabilities between CHUI and some combinations of hardware/software.

In fact, for almost a year, I was pretty much sure that the way CHUI renders text, using a different pipeline order, was causing the problem on older Apple hardware, which, as you so well mentioned, probably has older OpenGL implementations. So, my assumptions for all those months were that the problem would be "unfixable" — probably Apple's OpenGL on old Macs was reverting to software emulation, or hitting buffer limits, or something cryptic like that, and LL wouldn't bother to "fix" things — you ought not to be using 2007 hardware to connect to SL anyway, yadda yadda...

Recent comments on the Firestorm JIRA, however, made me believe that I was completely on the wrong track. First, it was clear that this affects all graphics cards used by Apple (Intel, ATI, nVidea), and not only Intel and ATI (which I had tested). Then it was clear that the age of hardware and operating system was mostly irrelevant: people with recent Apple hardware and running Apple's latest Mavericks OS had precisely the same issue. And the final blow was getting reports from Windows 7 and 8 users, with top-of-the-line graphic cards, usually having 100 FPS everywhere, but experiencing incredible delays between key presses and characters popping up on the screen (as well as huge FPS drops).

So there is a class of users which have this issue, irrelevant from where they log in from, where they log in to, and whatever hardware, software, operating system, or applications they have installed. It's a much broader group then I thought. On the other hand, it's clear that it doesn't affect the majority of users, it doesn't throw any errors, it eludes any attempt to capture information from the viewer (turning fast timers on, etc.), and it is impossible to reproduce by LL's (or other TPV's) testing team.

So what could be common to all of them? That's why I think it's related to Internet Plugins, and the issue that Kitely pointed out with their plugin being incompatible with the "newer viewers" (which, coincidentally, also implement CHUI), made me think that the issue is related to Internet Plugins. After all, it's not the first time I had encountered similar compatibility issues which created the oddest issues with SL (but usually only when viewing media...)

Now we need more people to test it out. I've done a few tests with 3.7.4 and it is a bit better without any Internet Plugins, but eventually the chat delay will come back again. So there has to be something else additionally to that...

Link to comment
Share on other sites
  • Lindens
Monty Linden

Monty Linden

Posted
  • Lindens
Posted

Gwyneth Llewelyn wrote:

Now we need more people to test it out. I've done a few tests with 3.7.4 and it is a bit better without any Internet Plugins, but eventually the chat delay will come back again. So there has to be something else additionally to that...

I don't want to discourage anyone from stepping up and doing tests but I did want to add a technical clarification.  Web-based rendering is handled in ancillary sub-processes running the SLplugin image.  This provides a great deal of isolation between the viewer rendering paths and the rococo horror found in web frameworks.  I won't say a causal relationship is impossible.  But I would be incredibly interested should tests support it.

Link to comment
Share on other sites
Gwyneth Llewelyn

Gwyneth Llewelyn

Posted
  • Author
Posted

Monty,

Thanks for the clarification. Not being a professional programmer, and unfamiliar with the viewer code (the last time I looked at it and managed to compile it was for 1.7.X.... eons ago :) ), I was relying on some rumour I heard that most of the CHUI code is rendered using the built-in web browser, fully integrated in the UI. I tried to track down the place where I had read that, but couldn't find it. This was what led me to believe that Internet Plugins might play a role in it: if CHUI launches somehow some of the browser code, then it might launch the associated plugins as well, and some strange condition might make it respond the way it does (unlike the old non-CHUI code).

May I safely assume that this rumour I heard is wrong and that the CHUI code has absolutely nothing to do with the embedded web browser, then?

The truth is that, as you predicted, even without Internet Plugins, the keystroke delay issue is still present — I've tested it yesterday. The difference, perhaps, is that it takes far longer to manifest — 20-30 minutes in my case, as opposed to 2-3 minutes or even "instantly" as before. It could be a coincidence, which deluded me in believing the issues were related. I realize now that they probably aren't.

Pushing that idea away, I still have a much odder theory to test — coming from another piece of rumour, which I couldn't track down by googling for it — that is related to how CHUI required a change on the graphics rendering pipeline. In some of my tests, it seemed that I could postpone the moment when the chat lag/keypress delay hit by reducing the available memory for graphics. This is certainly odd, and I have to make sure I can replicate that consistently, even though there is a theory that would support that behaviour. Right now it was something I just noticed by mere chance: when installing a CHUI-capable viewer, either LL's or TPVs, and "forget" to set the graphics memory slider to the maximum (172 MB in my case, as opposed to the "default" 64 MB, which is all that SL thinks that my old Radeon X1600 has...), the bug doesn't seem to appear. But I really need to try this out some more; I labeled it just as "coincidence" during my testing...

Link to comment
Share on other sites
Theresa Tennyson

Theresa Tennyson

Posted
Posted

Gwyneth Llewelyn wrote:

Monty,

Thanks for the clarification. Not being a professional programmer, and unfamiliar with the viewer code (the last time I looked at it and managed to compile it was for 1.7.X.... eons ago
:)
), I was relying on some rumour I heard that most of the CHUI code is rendered using the built-in web browser, fully integrated in the UI. I tried to track down the place where I had read that, but couldn't find it. This was what led me to believe that Internet Plugins 
might
play a role in it: if CHUI launches somehow some of the browser code, then it might launch the associated plugins as well, and some strange condition might make it respond the way it does (unlike the old non-CHUI code).

May I safely assume that this rumour I heard is wrong and that the CHUI code has absolutely nothing to do with the embedded web browser, then?

The truth is that, as you predicted, even without Internet Plugins, the keystroke delay issue is still present — I've tested it yesterday. The difference, perhaps, is that it takes far longer to manifest — 20-30 minutes in my case, as opposed to 2-3 minutes or even "instantly" as before. It could be a coincidence, which deluded me in believing the issues were related. I realize now that they probably aren't.

Pushing that idea away, I still have a much odder theory to test — coming from 
another
piece of rumour, which I couldn't track down by googling for it — that is related to how CHUI required a change on the graphics rendering pipeline. In some of my tests, it seemed that I could postpone the moment when the chat lag/keypress delay hit by 
reducing
the available memory for graphics. This is certainly odd, and I have to make sure I can replicate that consistently, even though there is a theory that would support that behaviour. Right now it was something I just noticed by mere chance: when installing a CHUI-capable viewer, either LL's or TPVs, and "forget" to set the graphics memory slider to the maximum (172 MB in my case, as opposed to the "default" 64 MB, which is all that SL thinks that my old Radeon X1600 has...), the bug doesn't seem to appear. But I really need to try this out some more; I labeled it just as "coincidence" during my testing...

It's very possible the problem isn't with CHUI, but with another recent change that only affects Mac users - the viewer was re-written to use the new Cocoa Mac programming framework instead of the old Carbon framework which was previously used and which Apple is trying hard to kill off. Cocoa viewer users have had a number of issues with keyboard input, such as movement and hotkey use.

CHUI was added to the LL viewer in version 3.5; the change to Cocoa happened with version 3.6.5. With Firestorm's longer release schedule they went straight from 4.4.2 (no CHUI, no Cocoa) to 4.5.1 (yes CHUI, yes Cocoa - I'm fighting the urge to make some sort of candy bar pun for fear of being sued by Android.)

It would be interesting to see if you see the same issues with LL Viewer 3.6.4, the last version that had CHUI but didn't have Cocoa. I'm not sure if it was formally blocked yet - the download still seems to be available. If you try loading it make sure the automatic update option in Preferences is turned off.

http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.6.4.280048

Link to comment
Share on other sites
ObviousAltIsObvious

ObviousAltIsObvious

Posted
Posted

Ebbe Linden wrote:

The slow performance of group chat is being worked on. Several optimizations have been coded and now we're in QA to make sure it works as intended. I hope we see improvements in 2-3 weeks.

ooooooo, didn't they tell you? there have been some nice group chat fixes before, but once it gets better we start using it more, and the system saturates again. and then everybody yells at you for promising it would get better. i hope these changes have something in them that can save you from the egg and tomato brigade this time!

Link to comment
Share on other sites
  • 4 months later...
Gwyneth Llewelyn

Gwyneth Llewelyn

Posted
  • Author
Posted

I'm afraid that this is indeed the case... the lag is still there.

There is, however, a difference. Super-performant computers successfully 'mask' the issue. Recently I've been somewhat 'forced' to give up my ancient hardware — it was impossible to do some of my academic work related to Second Life and the Open-Source-Platform-Not-To-Be-Mentioned-Here because of this issue on the Cocoa code. The new computer has such a huge performance that the chat lag is almost imperceptible. It's still there, for those — like me — who know what to look for, but I can imagine that the majority of people will not notice a 'huge' delay, specially if they have never noticed it before (because they never had to log in to SL with 7-year-old-hardware).

However, I understand that this problem will very likely never be fixed. A year and a month has passed since the last release of a Mac viewer without chat lag issues whatsoever. As time goes by, the probability that everybody switches to super-fast hardware increases all the time. And going down from a minute-long delay between a key being pressed and a character appearing on the screen, to something that takes perhaps a fifth of a second, means that, for all purposes, there is no noticeable delay. Except that even on super-fast hardware you can still download an old viewer and compare them side-by-side — and see that there is no measurable lag whatsoever on text typing on the old viewers, while there is an ever-so-slightly lag on the current viewers.

In 18 months, computers will be twice as fast, and delays of a tenth of a second will not be perceptible to the human eye. So, effectively, the issue will be labeled as 'fixed' — because by that time it will be highly unlikely that 3-year-old viewers will still be allowed to log in (too much will have changed by then). That was my worst fear — which forced me to get a loan and buy a new computer. But I seriously suspect that not everybody is able to do that. And it feels somehow unfair, because there was nothing wrong with the old viewer and its non-Cocoa code from last year...

Link to comment
Share on other sites
  • 1 month later...
Theresa Tennyson

Theresa Tennyson

Posted
Posted

Ona Waffle wrote:

I am on a Mac, and have this issue for the first time ever today. Whats changed ? Update to OS X 10.10 Yosemite today.

 

See if turning off the menu translucency in Vista Yosemite helps. The chat lag is usually caused by low framerates and Yosemite's menu translucency may be bogging down your graphics system when its trying to use a high-load application like Second Life.

Link to comment
Share on other sites
  • 11 months later...
You are about to reply to a thread that has been inactive for 3113 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to topic listing
×
×
  • Create New...