[haiku-appserver] Re: Refactoring

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Fri, 01 Jul 2005 15:43:18 +0300

Stephan Assmus wrote:

Hi Adi,

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

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.

Very! :-)

        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.



bye,
Adi.

Other related posts: