Hi Adi, up front! Congratulations on your marriage!! Have great fun! I wish you the best of luck! > 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.) > What you say is useful only when clearing with the > background color. > At least IMO. What will you do with a line primitive which arrives > >from the client side? You want for every instruction to call N(number of > screens) > 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. 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. This way, the ServerWindow code would stay clean. Best regards, -Stephan > 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. The hardware detection code would have to be moved from AccelerantHWInterface to somewhere higher up the hirarchy. The only hard part is the support for multiple monitors in BScreen. No hurries though, I'm just thinking out loud. Best regards, -Stephan -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++