[haiku-appserver] Re: Refactoring
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sat, 02 Jul 2005 13:51:49 +0200 CEST
Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote:
> >> 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! :-)
Ah, communication finally works out :-)
> >>> 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? :-)
Yes, indeed :-)
> > 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?)
If it's a true multi-head card, it would probably not matter that much,
indeed. But there might be a lot of issues with this:
1) dependencies from one head to the other with respect to max.
resolution, frequency, whatever
2) maybe only one hardware cursor - can we move it around between the
heads?
3) special features, like duplicated hardware overlay (window on one
screen, full-screen on the other)
4) card memory must be divided between the cards (thus, a single
allocator for both would be wanted)
5) maybe only one head can be accelerated - can we switch them on-the-
fly?
6) maybe only one head with 3D acceleration?
7) probably more I don't think about - I would guess that these issues
could be taken care of much easier when the app_server knows it's the
same card, and when there are some functions that communicate between
the heads
In any way, I guess Rudolf could give us a lot more insight here (and
prove me wrong where necessary :)), and maybe he has already in the
archives of this list (or the IK team list).
I think mirroring itself can "easily" be done by the multiplexing
display driver.
Bye,
Axel.
Other related posts:
