Axel Dörfler wrote:
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.
Although I hold my opinion, go do was you wish. :-)
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.
Yes, this VirtualScreen would've done just that. :-)
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
Correct.
- 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? :-)
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". 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. What I proposed above is that there should be a virtual driver(VirtualScreen) which would pass to every real driver the (drawline) primitive.
bye, Adi.
