[haiku-appserver] Re: Refactoring

Hi,

Axel Dörfler wrote:
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. 

    phew! :-)

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. 

    OK, I see what you mean.
        Then we should do a class that fits for this case.

What about calling this new class Surface or Canvas? 

    Yes, Surface it fits, IMO.

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

    I agree completely.

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

    Aren't we doing just that? :-)

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.

I'm not too much into drivers... but why do you need to thread a multi-head card different than 2 separate cards? (because of the mirroring feature?)



bye,
Adi.

Other related posts: