Stephan Assmus wrote:
up front! Congratulations on your marriage!! Have great fun! I wish you the best of luck!
Thank you Stephan! I will send you guys some pictures from the wedding if you want. :-P
What I do not like in this model, is the fact Draw() is called multiple times for a single update request. That's what I meant with "it breaks the programming model".
I don't think he meant to call BView::Draw() multiple times. (But maybe you don't mean that either... so just ignore me if that's the case.)
No, not BView::Draw(), Layer::Draw().
What you say is useful only when clearing with the background color. At least IMO. What will you do with a line primitive which arrivesfrom the client side? You want for every instruction to call N(number ofscreens) times DrawLine() in ServerWindow? I don't think it's quite nice. Encapsulation is needed.
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! :-))
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.
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! :-)
The hardware detection code would have to be moved from AccelerantHWInterface to somewhere higher up the hirarchy.
Are you sure? Why?
The only hard part is the support for multiple monitors in BScreen.
Well... bind BScreen to the first screen in R1.