[haiku-appserver] Re: Refactoring

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 01 Jul 2005 17:50:57 +0200 CEST

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 

                "Although, the BeOS currently only supports a single screen, in 
        future it will let the user hook up multiple screens. One of the 
        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 
        coordinate system. If there's just one screen, it's the main 

        A BScreen object represents one screen. An application can have 
        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

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())

                ... access the screen ...

I really wonder why they made screen_id a struct instead of a simple 
For R2 or as a private API, we could also have BScreenRoster, similar 
to what BVolumeRoster does.


Other related posts: