On 4/13/07, David Reveman <[EMAIL PROTECTED]> wrote:
On Thu, 2007-04-12 at 11:57 +0200, Kristian Lyngstøl wrote:
> First, there are two fundamentally diffrent types of doing multihead:
> The "one big screen" solution, usually achieved with xinerama ,
> twinview or similar. This provides us with one Screen, and therefor
> one CompScreen structure. The output extens are retrieved from
> xinerama, or possibly randr (in the future?), I would assume.
>
> Then there is the less used "multiscreen" way, which gives two
> seperate screens; you can't move windows across them, but you can also
> change the viewports individually.
>
> Compiz allready has the basic support for both of these setups, but
> within the Beryl modifications, we had some important changes.
>
> First, the perspective fixes, or projection-matrix related fixes.
>
> "Bigscreen" multihead is drawn by drawing one head at a time, and
> moving the OpenGL viewport for each. The problem with this approach is
> that the projection matrix is NOT altered, so it is centered around
> each head. This introduces a problem when you perform effects on more
> than one head: Say you zoom the cube out, you will first zoom to the
> center of head A, then when it comes time to draw head B, it will be
> zoomed with regards to the center of B.
If you want to draw all heads as one, then we should probably make it
possible to do that and not try to emulate it by manipulating the
projection matrix.
That would be a good solution too. What were your main reasons for
drawing one head at a time? I'm also curious if there are any
performance benefits of doing that, over drawing one huge scenery (say
you're using 4 monitors or more, it'll be a pretty huge viewport). The
only drawback I can think of drawing in one go is offscreen areas,
usually caused by mixed resolutions, but could also be caused by
having 3 monitors, two placed next to each other and the last on top.
> In Beryl, we solved this by calculating the respective "global"
> projection matrix for each head, storing it, and switching the
> projection matrix when we switch the viewport. This works excellently,
> and introduces minimum overhead; Since the projection matrix is
> pre-computed, it's just a matter of switching. I can't imagine a more
> efficient or correct way of doing this, though maybe the
> implementation could be improved. Without the projection-matrix fixes,
> bigscreen multihead will allways zoom incorrectly, unless you
> introduce some modelview matrix transformation to take over the job
> that the projection matrix was made for.
>
> Then there's multiscreen, which is a diffrent chapter. Without the
> beryl-work in multiscreen, it's unusable. However, the changes may not
> be perfect. There are a few really minor situations where d->screens
> is used instead of passing the actual screen to a function, those are
> trivial to work out and there are some changes to "Screen grabs"
> (Screen grabs are broken by design atm; They grab input, but are
> screen-specific and are used to communicate(!) drawing-related events
> too.). We need to figure out what we want to do with screen grabs;
> What I did in Beryl was to make sure that the screen grabs are manged
> in a display-context kinda way, but it's not a good long-term
> solution. Without it, however, you'll be able to do things like snap
> both cubes to the top, unsnap one, and now you have 0 screen grabs,
> even though one cube is snapped and SHOULD have a screen grab, and
> basicly you'll freez if you try to use the snapped cube most of the
> time. This is just an example.
I'm not sure how useful multiscreen will be in the future. Once input
transformations and randr 1.2 is integrated properly there's nothing
multiple screens can do that one screen can't, except drive multiple
graphics cards. What are you using it for?
The main reason we fixed it up was for multiple graphics cards;
situations where a xinerama-hinted enviroment just wouldn't work.
After I started using it myself for development, though, I fell in
love with the ability to switch viewports independantly. I use my two
monitors for diffrent things, so I don't really want the viewports to
be bound to each other.
You're right that it's not terribly usefull, of course, but
considering Compiz is allready designed to handle it, I don't think
there's any reason not to support it at this point.
Some basic support for multiple screens should probably be there and I'm
interested in whatever fixes you have.
The screen grabs should probably be removed at some point and simply
replaced by exclusive keyboard and pointer grabs much like XGrabKeyboard
and XGrabPointer.
Maybe I missed something, but isn't that more or less exactly what
they do allready, except they're used a little bit more creativly?
> I've been wanting to redo some of the screen grab work by splitting it
> in two; Seperate what's actually grabbing input from what's used to
> signal that something drawing-related is happening.
I wonder if we need the drawing-related grabbing.
Not sure how we can avoid it completly, we'll still need to know of an
event was triggered as a side-effect of something that grabs the
screen or not. (EnterNotify events while moving windows/grabbing cube
for instance).
I'll start working on the multiple screen related fixes and see if I
can't get them to you.
--
Kristian
_______________________________________________
compiz mailing list
[EMAIL PROTECTED]
http://lists.freedesktop.org/mailman/listinfo/compiz
