Jump to content

Gwyneth Llewelyn

Resident
  • Content Count

    104
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Gwyneth Llewelyn

  • Rank
    Advanced Member
  1. 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...
  2. 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...
  3. Ha, I was too optimistic! 3.7.4 still has the issue. It's just that without any Internet Plugins, it takes much, much longer to appear. When it does, however, it's as bad as before — making chat, IM, group chat unusable. Relogging will somehow "reset" things, and even when logging back in to a busy text-chat area, it will give you more minutes of "normal" responsiveness... It's not fun relogging every 20 minutes or so, though.
  4. Update: under 3.7.4, eventually the issue appears again. It seems to be just a question of time. It takes much longer to appear, though. When it does, however, it's just as before — even without any Internet Plugins.
  5. @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...
  6. In my case, I had to track down where my browsers stored Internet Plugins (on the Mac, they're under ~/Library/Internet Plug-Ins and /System/Library/Internet Plug-Ins) and delete them. The hint I had was that I still had the Kitely plugin installed, but Kitely has abandoned it, claiming that it had serious problems with the "new way SL viewers do log in". It just happens that this "new way" was introduced at the same time that CHUI became incorporated into the viewer code. I'm not putting the blame on Kitely, it could be any other Internet Plugin interfering, but after suffering for almost a year from this bug, I'm happy to see that deleting the Internet Plugins folder fixed the issue for me. I'm also trying the recommended RC to see the difference! Thanks for the tip.
  7. If switching to compact view doesn't make a difference, try this: track down where your browsers store Internet Plugins (on the Mac, they're under ~/Library/Internet Plug-Ins and /System/Library/Internet Plug-Ins) and delete them. In my case that worked wonders!
  8. @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!).
  9. 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).
  10. Almost all TPVs do indeed use 99% of LL's code... with two notable exceptions: Radegast and Lumyia (the latter is only for Android). Radegast started as a text-based viewer for SL using libopenmetaverse (which was independently developed at the beginning and had absolutely none of LL's code) and has been adding more and more 3D features (to the extent that on most platforms it can effectively be used as a 3D viewer). They (allegedly) use their own rendering engine and stay away from LL's. Of course, it means that scenes render slightly differently, but, as time has passed, they tend to look more and more like LL's own code, which is definitely an outstanding achievement — and proof that, as a TPV developer, you really don't need to stick to LL's code, unless you really want to (which is what most TPV developers want).
  11. Not only it continues to work in 2014, but (shhh!) it even works under OpenSimulator... hehe. Thanks for the script, I was going nuts in figuring out how to compensate for the camera movement, and all that because I got the control grabbing function wrong! Silly me!
  12. A late welcome to Ebbe to Linden Lab, Second Life, the forums, and utter chaos being finely balanced on the tip of a needle No, wait, now I remember: the first welcome message to Ebbe from me was on Twitter... Anyway, it's nice to see, for a change, someone with a lot of background in social media and online communications at the helm of Linden Lab. It sure should give us some hopes that at least, this time around, we'll see better communication. And that's certainly quite welcome! There are some pearls of wisdom at the LL board. We started with visionaries, like Philip Rosedale and Cory Ondrejka to get the ball rolling, even without knowing what direction it would take. Mark Kingdon saw an opportunity in expanding Second Life into the "serious" market and tried to turn it into a virtual 3D communications tool for enterprise and academic users. This didn't work so well at the corporate level, but did wonders in the research community: thousands of scientists are engaged daily in researching lots of aspects of virtual worlds (even though, because of the high cost of leasing land in SL, they do it now mostly on OpenSimulator — but all their work applies to SL as well). There are a handful of peer-reviewed scientific journals which practically only publish research on and about SL. I might even be so bold as to claim that "virtual world" and "Second Life" are now synonymous; few alternatives exist, after all, and probably the last serious one (Cloud Party) has gone with all the others. Second Life, by contrast, remains long-lived in spite of everything. Rod Humble had a background in artistic game design, and he worked incredibly hard to fix bugs, add astonishing features — some of them in the pipelines for almost a decade! — and coming close to reach the impossible: on a high-end computer of the latest generation, Second Life is almost impossible to recognize. Long are gone the days of the "2007" look, images of which are still appearing on the mainstream news media. Gah! We have gone a long way since that. Rod also managed to diversify LL's portfolio, and turn SL's success and profits into a source of financing for LL to launch new products. This was rather clever. In this era where two people with a computer and a programmer's handbook are able to grab a business angel, suck them dry, and waste millions after two or three years, it's refreshing to see LL and its financial resource allocation into R&D of new platforms as a functioning alternative to the "usual" ways of funding new development. Sure, not all "new products" are a success (or at least, not yet). But Rod proved the model worked without throwing LL into debt. He also recognized the potential of SL itself as a way to develop prototypes for games, by looking at the clever things that the RPG enthusiasts are doing in SL. In SL, content is king, so getting designers the ability to create even more fantastic content (like meshes!) created a veritable Renaissance in SL. I remember this old image from Khannea Suntzu, made in 2009: http://gwynethllewelyn.net/2009/05/21/khannea-suntzus-preview-of-second-life-in-2009/ This was rendered on a top 3D modelling tool at the time, and she predicted that the SL renderer would be able to achieve those results by 2020. We laughed at her. And ironically, we actually get that kind of quality today — if not better. Now it's your turn, Ebbe. For ages we have waited for a substantial improvement in SL as a communication tool — not only between LL and SL residents, but obviously among SL residents themselves. The way in-world text chat works is still stuck in the late 1990s — despite all improvements over the years, it still feels that the whole chat environment is not better than IRC running on a battered 486 with 512 KBytes of RAM and a sub-GHz CPU. We have my.secondlife.com, and some tentative integration with Facebook here and there. We have these clumsy forums where I'm typing now, which are invaded by spam every day (and yes, that's where most of the daily 10-12k registrations come from — not to join SL, but by spambots hitting the forums). Tickets (either in JIRA or elsewhere), abuse reports, requests for support and intervention by Linden employees — all those need a rehaul, mostly policy-wise, and not necessarily tech-wise. So there is really quite a lot to improve, just on the communication side of SL. And it's desperately needed. Content is indeed king, but communications is its queen: we don't need merely to be able to buy awesome content, we need to be able to talk about it Therefore, Ebbe, even if you don't stay at LL for a long, long while, you'll definitely have your hands full with things to do. It's definitely very kind of you to waste some of your precious time just to chat a bit on these forums, merely a week after you first sat on your chair That's an accomplishment, but the truly daunting challenge will be to keep it up over time. I sincerely wish you the greatest success in your new role at the helm of LL — after all, our (virtual) lives depend on it. Cheers and good luck!
  13. Ok, after much Googling, I found one solution. Apparently, this error is all wrong: it has nothing to do with "materials", but with a mesh which is too complex. The solution, for me, was to get Meshlab use one of its simplification algorithms to get a much smaller mesh. This is naturally tricky, the better the algorithm, the more horrible the result. Sometimes, just a 10% decrease in complexity is enough for SL to accept the mesh and get it working. Things are also not always obvious. Some objects seem very simple in Meshlab, but SL has a different opinion. And some objects upload fine to SL, while Meshlab crashes with their complexity! However, if you get this error and Meshlab is able to open your model, the good news is that you can use the simplification algorithms to see if you get a barely acceptable mesh that SL will import.
  14. I'd love to know the answer too! I'm going to continue to Google for it...
×
×
  • Create New...