[haiku-appserver] Re: Refactoring
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sat, 02 Jul 2005 09:29:05 +0300
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:
