Multiple Monitor Support

[Alec Kaestner]

One of the peccadilloes of the Linden Lab SL viewer (and TPVs) which has been bugging me of late, is the support for multiple monitors.

Now, I'm not talking about being able to extend your screen across two adjacent monitors, I'm talking about the ability to pop out, and move chat windows, notecards, HUDs, etc off to a second monitor, leaving a 'clean slate' for SL in all its SLishness :-).

Now, I'm not a programmer, but I wonder if some smart viewer programmer would be able and willing, to rise to the challenge, and garner a legion of fans (or at least, just me).

[Mollymews]

this is one of the hard problems of input and output balancing which is still waiting for a real-world solution

is not just a SL problem. It affects every game title as well.  Pretty much, only super fast internet connections and super fast hardware is going to make this possible

 

[Paul Hexem]

The Microsoft Flight Simulator games used to do this, and it was wonderful, being able to put various displays and windows on other screens.

Most productivity (Blender, Gimp, Photoshop) software allows it.

It's something we've wanted for SL for a long time, but nobody seems capable of making it happen.

[bigmoe Whitfield]

okay this is real and nobody ever picked it up, I wish they would have,  https://www.firestormviewer.org/introducing_firestorm_dui/

 

 

[Mollymews]

11 minutes ago, bigmoe Whitfield said:

okay this is real and nobody ever picked it up, I wish they would have,  https://www.firestormviewer.org/introducing_firestorm_dui/

the Firestorm DUI effort ran into the same input / output balancing problem that every other real time interactive 3D graphics online effort runs into

the problem is balancing (inward packet data. Keyboard, mouse, devices, etc) and output (outward packet data, screen display, sound).  The issue is that all of this is typically done within a single game loop to get performance.  Threading doesn't typically help, as threads are driven from within the game loop.Starting, stopping and keeping threads synchronised can often take more time than performing the tasks linearly

we can't hack a single loop program, spawn a whole bunch of slave threads and get performance just because threaded.  This is not to say that it isn't doable with high end hardware, but requires a whole other design paradigm

as pointed out, other types 3D graphics programs do have this capability, but they don't have to deal with lots of data packets (mulit-object and multi-user real-time interactions, etc) in the same way that games and worlds like SL have too

 

[Henri Beauchamp]

On 6/7/2020 at 1:17 AM, Alec Kaestner said:

I'm talking about the ability to pop out, and move chat windows, notecards, HUDs, etc off to a second monitor, leaving a 'clean slate' for SL in all its SLishness :-).

This got nothing to do with multi-monitor support (neither with threading, as mentioned in replies), but with how the viewer UI is implemented.

Indeed, the first time I launched a SL viewer (back in 2006), I have been extremely surprised to see that the UI (menus, floaters, panels, etc) was all rendered in OpenGL, which is a rather costly way of dealing with an UI, when GTK+, Qt (for Linux) or native OS UI elements (for Windows and macOS) could be used instead (at zero cost in term of frame rate)...

Back at that time, the CPUs were mono-core ones (with barely a quarter of the power of one of today's CPUs single core), the GPUs were 1000 times slower/less powerful than today's GPUs and the OpenGL UI consequently did represent quite a significant fraction of a 3D frame rendering time.

While that choice (rendering everything in OpenGL, UI included) could be seen as very disputable back in that time (mainly because of performance concerns), it did yet bring a number of advantages:

1. It is fully cross-platform, providing the user with an uniform experience in all three OSes the viewer could be run under.
2. It is easier to maintain for viewer developers (no need to deal with each OS UI peculiarities, or even with several UI toolkits for the same OS such as GTK+ and Qt under Linux).
3. It allows for a tighter bind between the viewer code and the UI (easier to keep UI elements in sync with what happens in-world).
4. It inherently provides a non-blocking UI (since the UI is refreshed in the main loop, not blocking the latter waiting for the reply of an external UI toolkit itself dependent on the user actions), and this without the need to use threads.

It also must be noted that it is how most games are coded anyway...

One of the drawbacks (beside the frame rate performance impact) is that you cannot drag an UI element out of the 3D rendering window.

Quote

Now, I'm not a programmer, but I wonder if some smart viewer programmer would be able and willing, to rise to the challenge, and garner a legion of fans (or at least, just me).

It is doable (it would require heavily modifying the llui viewer library to use a toolkit such as Qt or wxGTK), but not an easy task either and would be quite time consuming...

Edited June 8, 2020 by Henri Beauchamp

[Mollymews]

a discussion about threads and cores is here. I just put this here as sometimes people will ask how come SL doesn't use all the cores on my computer. Henri has explained the history, advantages and disadvantages of the current viewer design. The discussion linked to helps to explain what needs to be considered down on the metal when designing a multi-core capable viewer

https://stackoverflow.com/questions/11835046/multithreading-and-multicore-differences