Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote: > Stephan Assmus wrote: > > Somewhere, you will have to Draw the same primitive multiple times > > for each > > physical screen. > At least we agree on this one. :-)) There's no other way! :-)) Definitely not :-) > > I'm also not sure yet where to do this, but certainly it is > > going to be somewhere. Maybe we should have another ("master" or > > "intermediate") DisplayDriver class that encapsulates "real" > > DisplayDrivers > > and distributes the drawing commands to those. > Yes, this is exactly what I'm proposing a VirtualScreen class. > (with it's attached virtual HW Interface (funny combination of words > :-P) ) > > > This way, the ServerWindow code would stay clean. > Very! :-) Ah, for the first I see a benefit of a VirtualScreen class. Still, the Screen class we have now cannot be used for that at all; the interfaces don't fit - all that's equivalent is getting the display driver. I don't think the HW interface can or should be combined to a single class; a VirtualScreenHWInterface could not understand SetMode()/ GetMode()/GetModeList(), ... in a good way. What about calling this new class Surface or Canvas? It could export a single display driver to the outside world (either the one from the one physical screen, or a multiplexing driver when there are multiple). It would need a more sophisticated interface for how the screens should be layouted, as well as give access to the physical screens themselves (for the display_mode stuff). > > > What I proposed above is that there should be a virtual > > > driver(VirtualScreen) which would pass to every real driver the > > > (drawline) > > > primitive. > > Yes, I think this could be a DisplayDriver class. I think this > > approach is > > so simple, we could even have this ready for R1. > From what I can tell, Axel really wants this ready for R1! :-) Sounds good :-) I think it's important that the design will allow most of the changes we want to do later as well. Wether or not the MultiplexDisplayDriver will be there or not is less important - although it would certainly be great to have it :-) If we really want to think ahead, we should already sketch out a better accelerant API that understands multi-head; and this should then be the basis for HWInterface. AFAICT the changes would be minimal to that class anyway. > > The hardware detection code > > would have to be moved from AccelerantHWInterface to somewhere > > higher up the > > hirarchy. > Are you sure? Why? Yeah, why? :-)) > > The only hard part is the support for multiple monitors in BScreen. > Well... bind BScreen to the first screen in R1. BScreen already has support for multiple monitors, quoting from the BeBook: "Although, the BeOS currently only supports a single screen, in the future it will let the user hook up multiple screens. One of the screens, the main screen, will have the origin of the screen coordinate system at its left top corner. Other screens will be located elsewhere in the same coordinate system. If there's just one screen, it's the main screen. A BScreen object represents one screen. An application can have more than one object referring to the same screen. When multiple screens are supported, a screen_id identifier will be assigned to each one. Currently, B_MAIN_SCREEN_ID is the only identifier." IOW all that's missing is a way to enumerate the available screens. But since B_MAIN_SCREEN_ID is currently 0, we could use code like this to do this: for (screen_id id = B_MAIN_SCREEN_ID;; id.id++) { BScreen screen(id); if (!screen.IsValid()) break; ... access the screen ... } I really wonder why they made screen_id a struct instead of a simple typedef. For R2 or as a private API, we could also have BScreenRoster, similar to what BVolumeRoster does. Bye, Axel.