Cool VL Viewer forum

I know that this viewer has a patch for preventing SLplugin from eating up the CPU, which may be very dangerous for the computer. I am talking of course about people using linux (does this problem exist for MacOS as well ?). This patch was never integrated to Phoenix: Phoenix's developers do not care at all about this problem. So each time i want to use a new version of phoenix, i must first use your patch on phoenix's sources and rebuild the sources. The problem is even more critical for Firestorm which uses SLplugin all the time. And of course nothing is done either by Firestorm's developers, which makes this viewer almost unusable under linux (I wrote something about that in their blog). Now my question. I knew that that was a old problem, never solved. But I tried out recently Imprudence, which even provides a linux 64bits version of the viewer. And what a surprise ! Guess what ! In both linux versions (32bits and 64bits), SLplugin takes not more than 4-5% of the CPU !! Since you do care about this problem here, I thought that you could be interested in this information.

Dahlia Orfan.

Because Imprudence is based off v1.23.5 instead of Snowglobe, and v1.23.5 uses the old Mozilla-based web plugin (which doesn't have this CPU power consumption problem, but which would probably fail to render the new web search & Co), instead of QtWebkit...

Your best bet is to create a new JIRA issue (if there's not already one opened) and complain there about how the QtWebkit plugin makes viewer 2 unusable under Linux.

Satomi Ahn has found the solution: http://jira.secondlife.com/browse/EXP-700

Yes, indeed, she just did it !

Her fix will be part of v1.26.0.14 which will allow to get rid of the plugin "nicing" under Linux/MacOS (which will also provide way better webkit plugin responsiveness for single core CPUs).

Thanks for the pointer !

Update on this matter: I finally cornered down the primal cause of this issue.
It was yet another locale mess.

Viewer binary: locale forced to C (since some other xml bug that was fixed long ago)
SLPlugin: locale remains that of the system (fr_FR.UTF-8 for me)

If you happen to have "," as decimal separator, or anything that is not a ".", then sscanf would not be able to correctly scan a float whose decimal separator was "." (and the viewer using C locale, produces such a number format), stopping at the "." and reading 0.

The right way to fix this bug is to force the locale to C. (best done somewhere relevant in the program, maybe in LLPluginMessage, but try running "LANG=C ./secondlife", you will see it actually suffices to make SLPlugin nice again).

If I could get a hold on the guy who decided that sscanf() had to be made locale-dependent... Damned idiot !!!

No, this is not the "right way", since the affected function is part of the llcommon library and could be used for the same purpose (and with the same issues) elsewhere in the viewer code... and since it would be extremely unreasonable (and costly) to set the locale to C before the sscanf() and reset it to what it was after the call, the best thing to do is simply not to use sscanf() for parsing floats... This is what I did for v1.26.0.14. Problem solved.

Thanks for your work on this long standing bug, Satomi !

Whatever works .
As long we keep in mind that other locale dependent calls may still be lurking in the shadow, waiting for the first occasion to transform into nasty bugs.

You're welcome. Glad to be rid of that one anyway!