|
|
|
[
Permlink
| « Hide
]
Michelle2 Zenovka added a comment - 01/May/08 05:50 AM
Linking to VWR4572 as this is what was happening pre Dazzle and may in fact be the same thing, but what i report here the complete font corruption is 1.20.X specific.
Problems occurring as well on my ATI Radeon IGP320M under Ubuntu Linux 8.04.
Problems were NOT occurring on Dazzle RC2, only RC3, RC4, RC5 and RC6. Font Problems were also occurring in all older 1.19 and before releases. I'm keep watching on the "font breakage" issue on Linux since I saw
Your Screenshot-2.jpg is very interesting. It shows a misbehaviour of SL not just font handling, but it failed to draw something else, too (on the upper parts of the screen.) It makes me think that the cause of this issue is not SL's font handling, but misbehaviour of some GL interface... I would strongly guess that Screenshot-2's corruption is unrelated, and just a symptom of having a partially-obscured window when the snapshot was taken.
Hi Tofu, its a bad snapshot in this case but the corruption effect is consistent. It does not matter if i have all other windows closed, open or indifferent. Partially covering the viewer or not at all. The corruption is instant and 100% repeatable on my hardware. I'm currently stuck on 1.19.1 on my laptop now as 1.20 is unusable on my setup.
I'm actually using mesa-dri for the 3d as i don't have accelerated drivers for the card. I agree that its probably ATI related but as i said previously something in the viewer has changed certainly from 1.19.1 and possibly from early 1.20 RC's to trigger this fault. I'm concentrating on changes in llrender/llfontgl etc to see if any of those have tripped this issue. Will report back after my rebuilds Hah, no, the corruption is constant. Hold on, I'll apt-get istanbul and grab an ogm of how impossible this is to use.
This is basically the fault of this series of ATI chipset – they're basically a Radeon 7000 with the hardware texture and lighting part of the core removed. Therefore, Mesa has to compensate. Under Windows, SL won't even run unless you trigger the wireframe hotkey within 3 seconds of the login bits fading into inworld. Anyway, trying istanbul and gtk-recordmydesktop to grab hard evidence of exactly how bad this is. Here's a OGM containing how RC2 works.
(For the record, it works pretty nicely!) So the ATI is to blame but i wonder if it is possible to work around in some way. I did some further tests yesterday and 1.20 RC2 is effected in a slightly different way on my system to RC4/RC5. I have a far smaller amount of corruption on RC2, if i look at the object window the really weird thing is only single digit numbers go corrupt. If i change any value from (for example) 0.0 to 0 it corrupts, if i add an additional digit or decimal it displays again.
I just wonder if there is a workaround?, its a show stopper for me as i need to run SL on my laptop and i can't afford a new laptop Actually if mesa is compensating then this is a mesa bug? not an ATI bug as mesa is doing the 3d rendering in this case? And here's the HORRIBLE HORRIBLE BROKENNESS that is RC3, RC4, RC5, and RC6. YOU BROKEDED IT BADLY!
Now, if you watched the RC2, you will see that you guys WERE doing it mostly properly before, and then in RC3 you broke something. Both of these videos are from the same machine, same files, recorded only minutes apart. (This one's a bit longer to accurately display the HORRIBLENESS!) Well, yes, the true problem is within the ATI chipset, but as you can see from the two file attachments above the screenshots, this is also a problem in how SL is using GL on our laptops.
RC2 works very well when you edit up gridargs.dat and change the channel. Currently, that's the only workaround so far, keep in mind, with the gridargs.dat channel edit, you can get on with practically any 1.18.0+ client. As I mentioned, somewhere between RC2 and RC3, a change was made in the GL pipeline that VASTLY increased the scope of this bug. I've been running SL on this laptop since 1.17, and it's always exhibited the "one-pixel lower vowels" behavior, I assume this part of it IS a bug in Mesa, as this is the only PC it happens to me on. Now, how mesa works: It's a shim between the hardware 3D driver and the application's OpenGL interface, providing a generic GL interface in software. Any features the hardware cannot directly support, Mesa will emulate in software. In this case, since the ATI Mobile Radeon 3XXM chipset is incapable of doing hardware texturing and lighting, and so Mesa is picking up the slack in that area only. Everything else is falling through to the hardware to perform directly, such as rendering, geometry calculations and transforms, and such. I have been petitioning LL to test with Mesa on linux and windows for over a year, as you can see from my previous JIRA entries: http://jira.secondlife.com/browse/VWR-520 However, I know LL's busy, but they REALLY need to track this one down, as it's probably effecting other graphics adapters in subtle ways and could be contributing to crashes on more modern NVIDIA hardware, considering the GeForce 8xxx and 9xxx series cards (NV50 architecture) have dropped hardware support for older command types, which the Nouveau folks have noted in the OSS initiative for Nvidia drivers. http://nouveau.freedesktop.org/wiki/FrontPage This basically means modern Nvidia cards are using fancy software tricks in their drivers to emulate things the same way MESA is doing it for applications using older OpenGL 1.1 and 1.2 interfaces. (Yeah, I'm a hardware geek, so sue me... Oh, and I'm in the California south bay area (Mountain View) if any friendly linden would like me to tote the laptop into either the Mountain View office or the San Francisco office to take a peek at it. I'd be honored to have linden hands at my keyboard.
Does it help to edit the secondlife script and allow 'export LL_GL_BASICEXT=x' ?
Hi Tofu, afraid not, tried LL_GL_BASICEXT=x and LL_GL_NOEXT=x no effect with either.
Something i did just notice, looking very carefully at the corruption its as if the background color of the glyph is set to black (or at the same as the font foreground). If i highlight the text so that the font color changes to white i can see the numbers but only if i do not highlight all the numbers in a particular box. Could it be simply something not initalised in the GL somewhere, that does not effect other systems as they make a different inital assumption? Precisely what graphics card are you using Michelle2?
An imminent release (fairly likely 1.21 or the last 1.20RC) has some new GL debugging menu options which are supposed to help track down problems like these assuming they're a viewer bug on a supported config. Going to sound a bit thick here but i don't precisely know. lspci is reporting as the Radeon IGP 330M/340M/350M family. Chipset ID=0x4337 No further details anywhere else. Its a laptop so i would have to strip it to physically look and that might still be any more specific.
I'm building RC6 now to see if it has the extra options Go ahead and attach/upload your /var/log/Xorg.0.log here, I can tell you the proper chipset and revision from that.
I'm running stock "Ubuntu" Hardy Heron 8.04, on a Fujitsu Lifebook S2020, using the ATI Mobility Radeon U1, better known as the IGP320M revision 1. The same problem occurs when booting from my ShipIt pressed Feisty 7.04 and Gutsy 7.10 CDs. I'm using the "radeon" driver, since ATI's fglrx doesn't seem to recognize my chip as a supported one. The only thing I've done since installing hardy cleanly from the release ISO has been editing my panel slightly and installing ubuntu-restricted-extras for flash, java 6, and some codecs, plus gtk-recordmydesktop to capture the video. I tried the env vars, but they make no difference. Any other info I can provide? Sorry Kamillion, keep forgetting to attach that xorg log.
Searching around this seems to have happened in mesa before. I could do with testing different mesa versions (i'm on newest) to see what happens and if a slightly older version helps at all. When SL starts, blocks were being shown for letters, but could login.
Tried installing SL over itself, didn't help. Used SL's uninstall, then installed SL, got worse. Now I see a black screen, no text, blocks for text or anything, logging in with SL username/pw doesn't show at all, only spaces for what was typed. The startup progress bar shows blocks for text. Once in SL, all is good. Creepy! Any suggestions to fix this? Leahcim, no solution that i know of.
What GFX chip set do you have? searching the internet does show this happening with mesa in the past at various versions etc so i am pretty sure this is an cheap ATI/mesa interaction issue, but i do see some other strange effects on my effect system such as two home icons on the map and the no fly/no build icons are often duplicated as if the opengl textures have got out of sync some how. The thing is, the display use to work fine for the first half dozen logins. (Display is ATI Mobility Fire GL T2)
More info: Problem started when SL was running and I put the computer into sleep mode. Restarted the computer on a different wireless area. Downloaded the "Second Life Release Candidate" and installed while normal SL was installed. Are these introduction visuals some textures that I'm not pointing to the right way? Leahcim PS: "mesa" ? This issue was resolved as "Needs More Info" during a batch clean-up of PJIRA issues.
Reason: for an extended length of time, this bug seems to be missing enough details (reproducible steps) for Linden Lab to import the bug and investigate. Also the last affected version of the viewer on this report is viewer 1.21 or 1.20, 1.19, or even earlier, which are versions that are no longer actively supported. It is possible that this bug is indeed valid and should remain open-- however, Linden Lab needs the following pieces of information before it is Reopened: To reopen, please do all of the following: (1) It is very important to confirm that this bug still occurs in the latest official version 1.23. Please upgrade to that version by browsing to http://get.secondlife.com (2) If so, then please Reopen this issue and BE SURE to choose the "Affects Version/s" = 1.23 (3) Also, re-describe the steps that another person can follow to experience this bug. An example of a good "recipe" for a bug report can be found here: https://wiki.secondlife.com/wiki/Issue_tracker#Guidelines_for_a_bug_report (4) Come and attend the inworld bug triages, where you can meet with Linden Lab employees to consider, verify, and expedite bugs for fixing. For more information, see http://wiki.secondlife.com/wiki/Bug_triage Thank you for helping us improve Second Life! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Normal
Corrupt fonts
