Henri Beauchamp

This is not a ”requirement”, just a possibility offered to advanced and motivated users... Requiring TPV developers to implement a gazillion configuration options is not wiser, especially when a new user will be faced with such an enormous amount of configuration options that they will get lost. Not to mention code bloat...

Well, I was only half (ok, three quarters) joking, since you could indeed make the SL viewer screen amber and black, via a shader... 😛

The Cool VL Viewer got the Dark skin (by JB Craft): if the text background color is still too bright for you, you can edit it in skins/dark/colors_base.xml and place that edited file version in the override directory (as I explained in my post above)...

Nice... I got another suggestion. Add an option to make SL less of an eye sore, something like this, for example: 🤣

Suggestion: reduce the brightness of your screen (mine is set at 18%). Today's monitors default to a way too bright picture, ruining the black level (that appears light grey as a result) and thus the exploitable contrast dynamic, and destroying your eyes.

Not likely to happen any time soon...

Try ”Preferences” floater -> ”Cool features” tab -> ”Misc.” -> ”Frame rate limit”. Unlike VSync or LL's old frame rate limiter, which both ”sleep” the CPU and ruin the tasks performed in the main thread, aside from just rendering (e.g. textures fetching, rezzing, etc), this frame rate limiter won't impact the performances of the viewer while keeping, whenever there is headroom, your GPU and CPU cool, and their fans quiet. Yes, I am seeing this too when running the Windows build of my viewer under Wine... Perhaps the FTM is simply misplaced in the Windows part of the code and does not actually measure the swap time... I'll have to check it, time permitting (the Cool VL Viewer is primarily a Linux viewer, so such Windows minor glitches are not high on my priority list 😛 ). In the mean time, the Linux builds would give you relevant figures to measure the GPU+drivers performances.

Which would be the expected result, in relatively heavy render scenes; the Cool VL Viewer is better optimized at the C++ code level, which would blatantly show in frame rates in, e.g. a skybox with ALM off, with 600-1000 fps, depending on what your avatar is wearing (where Firestorm will give you 300-500 fps, at best). But we are speaking here about only 1ms per frame of difference or so, and since the viewers share almost exact same shaders, this won't make much of a difference once rendering ”everyday's” scenes. This boost factor (which is a multiplier to the RenderVolumeLODFactor when applied to mesh objects) should be 1.0 to compare with other viewers (that do not have it). Ah, yes... You'd have to use the Linux viewer to get this info (the Windows version does not have this FTM, IIRC)... I'll have to ”fix” that.

Careful with ”approximate”... If you wish to compare the viewer performances, you would have to use the exact same settings. The Cool VL Viewer is way more generous, by default (various ”boost” factors to render more detailed stuff, such as attachment and mesh LODs, the number and quality of the textures it loads, the number of objects it loads, and the fact it got a work around for objects that stay invisible at login or fail to rez after a TP, and so rez them properly)... The first thing that comes to my mind and could influence a lot the frame rate, is the field of view (FOV); the Cool VL Viewer got a default camera axis which is parallel to the ground (instead of pointing towards it in other viewers), meaning you catch more objects in the distance, by default...

In the fast timer view, look for ”Render” -> ”Swap”. To view it, you will likely have to fold the tree sub-branches of the Render branch (I did not modernize that rarely ever used floater, so it's still the old v1 one, without a scroll bar)

I made a quick test at your place and got the same result. It is true, that once the GPU is powerful enough and taken out of the equation, the viewer performances scale almost proportionally with the CPU single core performances. However, your Ryzen 3800X is just as good as my overclocked (5.0GHz) i7-9700K, if not better: while running 300MHz slower in turbo mode than my 9700K, the 3800X got twice the amount of L2 cache (same amount of L1) and almost thrice the amount of L3 cache (32MB against 12MB), which is very important for loads such as the viewer... Also, if your viewer got a ”Swap” fast timer, you could have a look at that figure: it reflects the amount of time per frame the CPU has to wait for the GPU to complete all the drawing calls, meaning it is a good measure of the GPU+drivers performances (the lower that time for a given scene, the best the performances). FYI, with the Cool VL Viewer, I get 5.5ms at your place for a 12ms total frame time (i.e. over 46% of the frame rendering time is taken by the GPU; ”over”, because there are other GL calls than the swap call which also incur (small) waits on the CPU side).

@Jenna Huntsman I could not measure at the exact same spot since it is protected by a security ”orb”, but on the nearby road, with the Cool VL Viewer, I get the same 80 fps at 160m DD (instead of 128), 4xAA + SMAA + sharpening shaders (instead of 2xAA + FXAA), Terrain & trees water reflections (instead of opaque water), 8192 particles (instead of 4096), everything else set to the maximum (including a generous 2x mesh LOD boost factor)... And this is only with an old GTX 1070 Ti and a Core i7-9700K, that is theoretically a less powerful hardware than yours (in particular, the 6900XT is supposed to be of the same class as a RTX 3080, which is waaaaaay more powerful than my old GTX)... This shows how plain lame are AMD OpenGL drivers... The proof is here (the blurry UI is due to the fact that I only have a 1920x1200 monitor and had to push the resolution to 3840x2400 in order to match Jenna's screen size: the scaling is causing the blurr):

AMD OpenGL drivers have always been slow. Even the new improved Windows drivers (which bring Windows drivers on par with Linux ones for AMD cards) will perform far less good than an equivalent (same price and hardware levels) NVIDIA card with OpenGL. The difference is enormous (like 50 to 100% more fps with NVIDIA).

+1 One often ignored (advanced) feature of viewers is that you can actually override most of their skinning, by simply adding modified xml files in the proper directory (e.g. for the Cool VL Viewer under Linux in ~/.secondlife/skins/default/xui/en-us/ ; for other viewers you may need to replace ”.secondlife” with their own directory, and for v2+ viewers, you need to replace ”en-us” with ”en”). This includes the fonts.xml file that you may then tweak and use with every viewer ”brand” on your system. You could also modify the note card XUI definition file (skins/default/xui/en-us/floater_preview_notecard.xml for the Cool VL Viewer) to use a specific font (the Monospace one, for example, or any other mono-spaced font present on your system); again with the Cool VL Viewer as an example, you replace '<text_editor name=”text_edit” font=”SansSerif” ...>' with '<text_editor name=”text_edit” font=”Monospace” ...> line 39 of skins/default/xui/en-us/floater_preview_notecard.xml. Doing the same thing for all viewers you are using, you would get a consistent viewing of note cards over them all on your system. But like Kathrine wrote, do not expect to do ASCII art in note cards and expect it to be properly displayed in everyone else's viewer(s). AFAIK, the Cool VL Viewer is the last viewer to use those (totally gorgeous) v1 fonts... Too bad, because DejaVu, Utopia & Co suck big time when compared to the old SL fonts... I made a lot of testing, when I considered moving away from the v1 fonts, but so far found no good replacement; the closest I found was Roboto condensed v1.00000 (2011 version).

gmail, hotmail, yahoo & Co are all rejecting automated forum emails as ”spam”... Use a ”normal” (ISP based) email account, or right out a throw away email (if you do not care about risking forgetting your password), such as one made up via Guerrilla Mail or Temp Mail. I activated your account manually.

This one could indeed happen for people with modify rights on the objects and using viewers not (yet ?) having backported LL's corresponding fix. Note that it has been over two years that this fix was implemented, so it would mean an ”old” viewer, or one that is badly maintained...

This could be the result of the new renderer code that came with the performance viewer. Alpha rendering has changed... If you own the object, and it is mod-ok, you could try to change the alpha setting for the affected faces: try changing the alpha blending level (for alpha-blended faces) or the alpha mask cut-off value.

Without the viewer logs, hard to say for sure... If the issue gets solved by a relog, then my (wild) guess would be a failure to retrieve the materials data (with textures using alpha masking instead of alpha blending), either because of a network issue or due to a bogus/missing materials capability URL... Another possibility would be a texture cache corruption.

Yes, it is still in Wine v7.14. You can verify by installing the Windows version of the Cool VL Viewer and running it under Wine: while rezzing a scene, open the debug console and watch for ”WARNING: LLFileSystem::seek: Could not append enough padding bytes to seek to position: ...” messages; they are the result of that bug. Enabling ”Advanced” -> ”Caches” -> ”Flush on asset write (for Wine)” works around this bug for the Cool VL Viewer and makes the warnings vanish as a consequence (but it is at the price of a slow down on cache writes).

You should really avoid running viewers under Wine: they will run super slow and bugs in Wine will make you experience miserable (for example, there's a bug in file writes where the file pointer is not updated after the write unless an explicit flush is done, which will likely corrupt cache files). Simply use viewers that provide a Linux build. In order of appearance: Cool VL Viewer, Firestorm, Kokua, Alchemy. There is also Singularity, but it is outdated.

Fixed in v1.30.0.12 I just released.

Obviously, you did not look at my smart frame rate limiter code... Try it, and you will see... Cool and quiet, and yet blazing fast while rezzing. The trick is to sleep only once every ancillary task has been completed, and to sleep the main (=renderer) thread by 1ms steps (instead of 10+ ms straight like what happens with the driver-imposed frame rates), each time checking whether new stuff (textures, for example) has arrived via the other threads, so to complete the corresponding work before sleeping again if it is still ”too soon” to render the next frame.

This got the exact, same, catastrophic result as Vsync. Basically, at each frame, the CPU has to wait after the driver for the minimum frame duration to be exhausted (i.e. the OpenGL call does not return before the necessary time as expired). This causes massive slow down in rezzing since while it waits the CPU cannot perform any object data decoding, object LOD calculations, texture area/priority calculations/adjustments, texture fetching, texture decoding, GL texture creation, etc... This is BAAAAD ! 😝

This is a side effect, yes. Since the viewer renders more frames per second, the power drawn from the GPU increases... And indeed, sometimes, it can get a little overwhelming (especially when the GPU fans start roaring), thus why I implemented an optional frame limiter in the Cool VL Viewer (but a smart kind of frame limiter, that does not ruin textures fetching and decoding, for example, but on the contrary uses the ”free time” in each frame to load/decode more of them). With LL's viewer (and likely BD), your only option is to use Vsync to limit the frame rate (but it ruins the rezzing performances)...

I found a way to solve the alpha draw order issue for these heads (that hopefully won't break anything else). The fix will be in next release. Basically, for rigged meshes, I always preserve the legacy draw order (as computed in LL's latest fix/commit to MAINT-N viewer), regardless of alpha-sorting...