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.
