Would it be possible to have best of both worlds?
I mean have separate things by default and have an option in Screen pref or a config file allowing spanning? Just tell user that it needs an app_server restart and it will be slower. Also warn them that it shouldn’t be activated unless they have nearly identical monitors.
Architecture is quite different.
You are probably misreading what I wrote.
Screens either have the same configuration, or they don’t. In fact, you have a virtual screen that spans over all physical screens, and your screens are views to that virtual screen. That’s how the Be API works, and that’s how app_server has been built. If all screens are powered by the same graphics card, and their configuration is the same, the app_server can access the HWInterface, as if it would actually be a large screen.
The color stuff in hinting wasn’t there from the beginning. Hinting just means that you actually change the font such that it will better fit the pixel resolution. Since the font is changed, it will have different pixel sizes on screens with a different DPI (when you apply scaling, of course, because only then it actually matters) Apple didn’t have high resolution displays a couple of years ago either; all fonts always looked blurry in OS X before that.
If you change app_server in a way that it cannot span a window over two screens, you effectively forbid that, because there is no technical reason not to allow it.
That is maybe how it is coded now, but it isn’t how it should work, for the reasons I’ve outlined above.
This design makes it impossible for userspace applications to properly deal with different pixel order (for color hinting), determining monitor edges, opening dialog boxes in the apropriate places, dealing with cursor and text field focus properly, dealing with correct color spaces of the display, dealing with display gamme correction etc. etc. etc.
Add to this that the rectangular nature of the “virtual” canvas of this setup makes it easy to accidentally “loose” windows.
The only setup this would work okay is two identical displays right next to each other with no visible edge at all.
And even then, different production runs sometimes still need different color correction on the same monitor build.
If you want windows to show “over” an edge, on two screens, should be done higher up in the stack as such, if it is needed at all.
I’ve outlined several technical reasons why this design is a terrible idea, so I really don’t see why you claim that there is no technical reason for this.
1 Like
I’m with @nephele on this one. Amiga tried to use multisync monitors to support different scan rates and it blew up in their faces when they tried to do split-screens with different scan rates on the same monitor.
We should be doing split screens to keep different monitor characteristics from conflicting with one another. If scan rates aren’t identical, tearing can occur. If pixel formats differ from one display to the other, the bitmaps can’t be shared. If multiple discrete graphics cards are installed their video RAM won’t be shared.
I still cannot follow you. The window placement issue aside (we already provide functions for that), everything you mention is nothing applications should deal with, and can, and should completely be handled within app_server. That it is a large virtual screen internally is completely irrelevant besides for the fact when you move windows or the even the mouse cursor between the screens. Screens are, in fact, part of a larger canvas, and cannot be seen completely independent from each other, or else things like moving the mouse cursor between them wouldn’t even be possible.
What I meant with technical reasons (you have to deal with everything you said anyway (again besides window placement), no matter where you differentiate between the screens), is that with the current layout of the app_server, it makes no difference, if you would allow it, or not. Not allowing would even be more effort than allowing to have a window to span over more than one screen.
Again, I see no reason, why I, as an application developer, should not be able to have a window span over two screens. Or should have any problems doing so. All the details, like tearing, font rendering, gamma, and whatever you mention, is nothing an application developer should have to deal with at all.
From a technical point of view, you have to deal with all the details anyway when drawing onto difference surfaces; it doesn’t make any difference if what you are painting is part of a window, or the complete window.
1 Like
It is perfectly possible. Each screen can be handled independently in its own desktop thread and screen adjustment information can be used only to wrap cursor between screens and to show multi-screen Workspaces view allowing to drag windows between screens. Dragging windows between screens can work in the same way as currently dragging between workspaces is done.
No single canvas concept is needed. It introduce additional vector command forwarding overhead. Haiku already have slower graphics compared to BeOS, lets do not introduce additional overhead. There are a lot of problems if considering all screens as single canvas as @nephele mentioned (different UI scaling, different refresh rate, different color space, color management, some screen is remote one etc.).
1 Like
Professional well-designed software allows to open multiple windows that display single model in different viewports. So spanning windows are not really needed for content creation work.
Blender for example. One can easily imagine placing second window on another screen.
3 Likes
there are really only 3 types of multi monitor uses.
-
2 identical screens each with a shared desktop view, this is popular in office envirments, ie documents open in different screens, often used for research, sometimes more than 2 monitors.
-
a cluster of screens all being used as a much larger virtual monitor, ie a large led screen wall with multiple monitors, often used for a entertainment venues video production etc.
-
mixed size multi monitors for things like a CNC machine. you might have 1 touch screen with a main UI and additional smaller screenda with additional functions.
those are the 3 main types of multi monitor uses i am aware of.
Add ‘two identical screens plus the screen of the laptop they’re connected to’ and ‘screen for presentations plus laptop screen for something else’ along with countless other setups. There really isn’t anything that simple.
Second use case is very commonly used in business environments. Frankly, it is nuts not allowing sharing a window among multiple screens. It shows how the developers here are out of touch with potential users. “I don’t use it, and it is complicated to implement” is not an excuse. Don’t reinvent the wheel, first reach the basic use cases, then innovate if you can.
It’s even funnier, when Haiku tries to become the next BeOS, the media OS, but not support basic media industry scenarios.
Addendum: It is also against the desktop metaphor. A window should remain where it was placed. As Tracker is still spatial, this is how it should be implemented.
This can be handled with common GPU framebuffer for all screens.
@bitigchi
I really apreciate how you managed to contribute nothing to the discussion, don’t adress any arguments but then go and say “the developers are out of touch”. You completely missed the point of Haiku, and it’s especially rude since X512 and me, who don’t have commit access, were talking with axeld who does.
Clearly “the developers” took your “side”.
If you don’t care for discussions on how to implement stuff, then leave, this is just how it is done with Haiku. And personally I have had enough of your toxicity.
Strawman argument.
1 Like
I see you are triggered as usual, son. You are out of form though, I thought you’d reply earlier.
I don’t really understand why there is such hostility to the idea of windows spanning monitors being supported as a feature. If you don’t want it, then don’t use it. I don’t see how supporting it will break anything else.
4 Likes
Of course, it’s possible. Anything is possible. It’s just not a very clever design to do so.
- You make it impossible to have a window span over more than one screen.
- You can never tell where the mouse cursor is from its coordinates alone.
- Screens have a real world physical layout. It just makes sense to span a larger canvas around them, and, even if you don’t want to admit it, it only has advantages compared to any other solution.
Haiku does a lot more than BeOS on drawing, and therefore it’s not easily possible to compare them.
I don’t like repeating myself, but you make it really hard not to: having the ability to have windows span over multiple screens DOES NOT SLOW DOWN ANYTHING.
2 Likes
Well, if you implement things by multiplexing HWInterface and not by using a single giant framebuffer, there will be a slight overhead of forwarding drawcalls to the appropriate HWInterface and/or clipping/transforming them as appropriate.
2 Likes
Maybe we need to see this from another angle. If you implement it that way, what would it mean for users who still have a matrox card and already have spanning? If the functionality disappears, they will probably see it as a regression no matter what you will say. If it can be reimplemented later and only disappears momentarily, they won’t complain.
the only time it makes practical sense for a window to spawn multiple monitors, is a video wall.
as a multi monitor users for work, i never do it, the border space is to hard to use along the screen edegs
In fact, most apps needing to span over several monitors will use a fullscreen view.
With tech progress and monitors thin as paper, edges size will reduce a lot.
I think that it is a bet on future. What is certain is that we will have bigger screens. The question is to know if monitors size will continue to become bigger and multi monitors setup will tend to disappear. IMHO, there’s a chance that such monitors won’t be affordable for common users and that modularity of layout will save multi monitors.