[haiku-appserver] Re: Refactoring
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 01 Jul 2005 12:34:43 +0200 CEST
Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote:
> Axel Dörfler wrote:
> >> Workspace should have a pointer to a VirtualScreen(n Screens)
> >>object.
> >>This lets you have 1,2,3,..,32 VirtualScreens attached to a
> > > RootLayer
> >>object, and every Workspace have that pointer to one of them(as set
> >>by a configuration (tool)).
> >> ( it would be nice (IMO) to have these classes:
> > > Screen(virtual),
> >>PhysicalScreen(mapped to a monitor), VirtualScreen(a spread screen
> >>composed from n PhysicalScreens) )
> > Why the effort? What's wrong with just Screen (or PhysicalScreen)
> > objects? A VirtualScreen and a PhysicalScreen would have very
> > little in
> > common, anyway.
> > The app_server would need to have a list of physical screens. The
> > Workspace object would need a list of screens that the current user
> > may
> > use at a moment (which will be the same most of the time, anyway)
> > and
> > their configuration (ie. display_mode, orientation).
> I don't see the difference from what I proposed. You use a list
> of physical screens, I use an object which maintains a list of
> physical
> screens.
> I like my approach better because the driver which will draw half
> a window on one screen, half in another will use the Screen derived
> class
> instead of a Workspace object.
> I want things to be clear, and for that reason I think using a list
> inside Workspace would complicate things and introduce code
> dependences.
Workspace needs separate Screen objects, because it has to store the
configuration of every single one. It also should keep this information
available when such a monitor is temporarily not available (and
therefore, doesn't have a Screen object at all).
With my first paragraph, I wanted to point out that the current
(Physical)Screen class and the virtual one do not have a lot of common
concepts - I don't think it makes sense to introduce a common base
class for them.
The driver does not know anything about the Screen class, nor about
workspaces.
The class responsible for drawing (RootLayer) will need to constrain
the clipping so that a single driver will only get what should be seen
on its Screen.
It must divide the surface into separate Screen objects, and must it
handle as such.
> > Yes, I think you're right. I always assumed that RootLayer could
> > only
> > handle a homogeneous canvas, ie. same resolution/color space.
> > If that's the case, though, we would need to change it, of course :
> > -)
> >
> > IOW RootLayer needs to have a list of drawing surfaces.
> Yes, taken from the current workspace.
Exactly. The workspace will also know how the screens are organized
"geographically", ie. which one is one the right, and which on the
left, or whatever.
> > Each surface
> > can have its own display driver and HW interface. IOW that's a
> > screen,
> > right?
> Yes, yes, yes... Finally, we understand each other! :-) Are we? :-)
I think so :-)
> > RootLayer would need to divide a redraw region into the areas
> > occupied
> > by different screens, and pass the display driver to the
> > Layer::Draw()
> > functions (the fDriver member would need to disappear).
> Yes!! :-) That's what I was talking about.
>
> However, things are a bit strange. They need to be cleared out.
> For example(the simplest): if a Layer is shown half on a screen,
> half on another. We can't simply call ::Draw(rect, Driver()), because
> of
> what I understood from above the driver would point to a particular
> HW
> interface(screen) and only half of that Layer would be drawn.
> Also, calling Draw(rect_clipped_to_screenX, Driver(X)) for every
> screen onto which this Layer appears is not an option because it's
> just not
> ... right(would break the programming model).
> So, we need to do something else.
> And here I think you don't agree with me. :-) That Layer only
> "sees"
> a region in which it can draw. the drawing that it does must be
> decomposed
> for the 2 HW interfaces onto which this Layer appears. That would
> need a
> VirtualHWInterface and a VirtualScreen. :-)
> If you don't agree, OK, give another solution.
Huh? I am not sure I understand you correctly.
That's how I think it should be done:
- a layer's regions (ie. fVisible, fFull, fFullVisible, and whatever
else there is :-)) are independent of the screens - they span over the
complete surface
- whenever a layer is drawn, the update is divided into separate
screens, for every screen, the layer would be drawn as such (in pseudo
code):
region = screen.region;
region.IntersectWith(layer.visible);
region.IntersectWith(updateRect);
layer.draw(screen, region);
And there we are.
So where do we now break the programming model, and if we do, what is
it anyway? :-)
> > That was not the topic here.
> OK, we'll talk another time about this.
Whatever that was about :)
Bye,
Axel.
Other related posts:
