[compiz] Multihead related issues
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. 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'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. A more serious issue is that we can't share display lists, and that we need to do OpenGL context switching when we're doing texture work. Dennis did some excellent work in that area, and it's not a problem in Beryl at the moment, but as he said himself; It's probably not the ideal solution. Personally I don't know the best approach to this; While context switching is generally slow, I don't see any real way out of it that would be faster, and it doesn't happen all that often even with Dennis' patches. The OpenGL context switching and sharelist issue is the big blockers, and where I hope I could get some input. I'm not sure it's anything we can do with lack of sharelist (?), and honostly, it's not my field of expertise, but let's see if we can't figure something out. There's one last thing related to bigscreen multihead, that hasn't been fixed in beryl either, and that's option handeling. Compiz-core of course has the ability to use diffrent options for diffrent screens, and I'd really like to see this in the storage backends. I'll admit I haven't been up to date lately, so I don't know the state of bsm for instance, but I'd like to bring it up now anyway. One use, to prove that it makes sense, is to have 6x6 viewports on the large monitor, but only 2x2 on the small (which is what I would want for myself). Most of the work shouldn't be to hard to port, but it would be nice to take this oppertunity to discuss the design and implementation. I know perspectives have come up on private e-mails, but since I don't know the details, I'm bringing it up here. -- Regards Kristian PS: The reason I've been a bit passive lately have been a combination of general IRL bussy-ness, and that I actually use multiscreen and just felt a bit demotivated that it didn't work. I'm prepared to start porting or re-implementing multihead-related work as needed. ___ compiz mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [PATCH] Resize improvements (Multiple resize modes, better aspect ratio constraining)
Hi,
I have ported various improvements of Beryl's resize to Compiz:
- multiple resize modes (aside to the standard "normal" mode those are
"Stretch", "Outline" and "Filled Outline")
- better aspect ratio constraining (you now also can resize aspect
constrained windows from other edges than the lower right)
- avoiding of mouse pointer desynchronization when the resizing hit
constraints.
While porting this, I cleaned up the code and fixed some performance
problems, so the code is supposed to work without problems.
If you want to use the new options and are using gconf, you have to do
'make compiz.schemas.in' in your plugin directory to update the schema
file.
Please tell me what you think of that patch and if you experience any
problems while using it.
Thanks for your feedback!
Regards,
Danny
diff --git a/plugins/resize.c b/plugins/resize.c
index b9eb42b..928fb23 100644
--- a/plugins/resize.c
+++ b/plugins/resize.c
@@ -42,6 +42,16 @@
#define RESIZE_INITIATE_KEY_DEFAULT "F8"
#define RESIZE_INITIATE_KEY_MODIFIERS_DEFAULT CompAltMask
+#define RESIZE_BORDER_COLOR_RED 0x2fff
+#define RESIZE_BORDER_COLOR_GREEN 0x2fff
+#define RESIZE_BORDER_COLOR_BLUE 0x4fff
+#define RESIZE_BORDER_COLOR_ALPHA 0x9fff
+
+#define RESIZE_FILL_COLOR_RED 0x2fff
+#define RESIZE_FILL_COLOR_GREEN 0x2fff
+#define RESIZE_FILL_COLOR_BLUE 0x4fff
+#define RESIZE_FILL_COLOR_ALPHA 0x4fff
+
struct _ResizeKeys {
char *name;
int dx;
@@ -60,8 +70,28 @@ struct _ResizeKeys {
#define MIN_KEY_WIDTH_INC 24
#define MIN_KEY_HEIGHT_INC 24
-#define RESIZE_DISPLAY_OPTION_INITIATE 0
-#define RESIZE_DISPLAY_OPTION_NUM 1
+#define RESIZE_DISPLAY_OPTION_INITIATE 0
+#define RESIZE_DISPLAY_OPTION_MODE 1
+#define RESIZE_DISPLAY_OPTION_BORDER_COLOR 2
+#define RESIZE_DISPLAY_OPTION_FILL_COLOR 3
+#define RESIZE_DISPLAY_OPTION_NUM 4
+
+typedef enum _ResizeMode {
+ResizeModeNormal = 0,
+ResizeModeStretch,
+ResizeModeOutline,
+ResizeModeFilledOutline
+} ResizeMode;
+
+char * resizeModes[] = {
+N_("Normal"),
+N_("Stretch"),
+N_("Outline"),
+N_("Filled Outline")
+};
+
+#define RESIZE_MODE_DEFAULT ResizeModeNormal
+#define NUM_RESIZE_MODES(sizeof (resizeModes) / sizeof (resizeModes[0]))
static int displayPrivateIndex;
@@ -75,16 +105,31 @@ typedef struct _ResizeDisplay {
XWindowAttributes savedAttrib;
int releaseButton;
unsigned int mask;
-int width;
-int height;
-int ucWidth; /* unconstrained width */
-int ucHeight; /* unconstrained height */
+
+int currentX;
+int currentY;
+int currentWidth;
+int currentHeight;
+
+/* offsets between pointer and upper left
+ window edge on resize start */
+int xDelta;
+int yDelta;
+
+int rightEdge;
+int bottomEdge;
+
+ResizeModeresizeMode;
+
KeyCode key[NUM_KEYS];
} ResizeDisplay;
typedef struct _ResizeScreen {
int grabIndex;
+PaintWindowProc paintWindow;
+PaintScreenProc paintScreen;
+
Cursor leftCursor;
Cursor rightCursor;
Cursor upCursor;
@@ -111,6 +156,38 @@ typedef struct _ResizeScreen {
#define NUM_OPTIONS(d) (sizeof ((d)->opt) / sizeof (CompOption))
+static void
+resizeUpdateRealWindowSize (CompDisplay *d)
+{
+RESIZE_DISPLAY (d);
+XWindowChanges xwc;
+
+if (!rd->w)
+ return;
+
+if (rd->w->state & CompWindowStateMaximizedVertMask)
+ rd->currentHeight = rd->w->serverHeight;
+
+if (rd->w->state & CompWindowStateMaximizedHorzMask)
+ rd->currentWidth = rd->w->serverWidth;
+
+if (rd->currentWidth == rd->w->serverWidth &&
+ rd->currentHeight == rd->w->serverHeight)
+ return;
+
+if (rd->w->syncWait)
+ return;
+
+xwc.x = rd->currentX;
+xwc.y = rd->currentY;
+xwc.width = rd->currentWidth;
+xwc.height = rd->currentHeight;
+
+sendSyncRequest (rd->w);
+
+configureXWindow (rd->w, CWX | CWY | CWWidth | CWHeight, &xwc);
+}
+
static Bool
resizeInitiate (CompDisplay *d,
CompAction *action,
@@ -186,12 +263,19 @@ resizeInitiate (CompDisplay *d,
rd->w = w;
rd->mask= mask;
- rd->ucWidth = w->attrib.width;
- rd->ucHeight= w->attrib.height;
- rd->width = w->attrib.width;
- rd->height = w->attrib.height;
rd->savedAttrib = w->attrib;
+ rd->currentX = w->attrib.x;
+ rd->currentY = w->attrib.y;
+ rd->currentWidth = w->attrib.width;
+ rd->currentHeight = w->attrib.height;
+
+ rd->rightEdge = rd->currentX + rd->currentWidth;
+ rd->bottomEdge = rd->currentY + rd->currentHeight;
+
+ rd->xDelta = 0;
+ rd->yDelta = 0;
+
lastPointerX = x;
lastPointerY = y;
@@ -250,6 +334,17 @@ resizeInitiate (CompDisplay *d,
warpPointer (d, xRoot - pointerX, yRoot - pointerY);
}
+
+ rd->xDelta = (x - rd->currentX);
+ if (rd-
[compiz] Reunification Discussion Mailing List
Hello Everyone, I have created a new mailing list for the purpose of discussing reunification related issues. You can find the subscription page here: http://www.rock3d.org/mailman/listinfo/compcomm I have periodic issues with gmail addresses so it would be better to use another address if you have one. If you use gmail, be sure to check your spam folder for your subscription announcement and mark it "Not Spam". If you have any issues feel free to contact me directly. I'll give everyone a day or so to subscribe, then I'll post a list of a few important topics to get the ball rolling. Jeff ___ compiz mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Bug with kde applications and damageWindowRect wrapping...
Here is a bug that make me insane since a lot of time. Randomly, when launching an kde application, i can see it appear on screen and then being placed by place plugin. I look at place plugin code and everything looks ok... http://hibbert.univ-lille3.fr/~cbellegarde/PlacementBug.png Here a screenshot of the bug, as you can see, window first appear at this "non placed" position, then, it will be removed and place by place plugin ... As all this is executing fastly, you get a really bad looking effect on screen... But, this only affect kde applications, i can't reproduce this with a gtk application Really don't understand what is happening :( If someone can confirm this bug ... Run this in an xterm with smart placement method: while true; do konsole & sleep 1; killall konsole; done Look at the screen, you should randomly see the bug at konsole window mapping... Bellegarde Cedric ___ compiz mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Strange behaviour in move plugin
Hi, > > One of the two last commit to move plugin make windows movements really > > strange and cpu usage really intensive... > > Strange in what way? > > One of the changes that was made is that the server side window position > is now updated after each motion event. This shouldn't really affect > performance by itself but the application, some pager or some other > application might be doing something performance sensitive each time the > position changes. While I don't have the sluggishness problems at all, I noticed another slight problem with the new code: Viewport changes caused by edgeflipping obviously cause a window movement by s->width / s->height pixels (depending on your edgeflipping direction). This big jump is animated by wobbly causing some "shiver" effect which looks pretty weird. This problem is normally obscured by rotate's flip time, but becomes visible pretty easily if you set this setting to a low value (such as 20 ms). Unfortunately I don't have a solution off-hand :-( Regards, Danny ___ compiz mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Strange behaviour in move plugin
One of the two last commit to move plugin make windows movements really strange and cpu usage really intensive... Strange in what way? One of the changes that was made is that the server side window position is now updated after each motion event. This shouldn't really affect performance by itself but the application, some pager or some other application might be doing something performance sensitive each time the position changes. While I don't have the sluggishness problems at all, I noticed another slight problem with the new code: Viewport changes caused by edgeflipping obviously cause a window movement by s->width / s->height pixels (depending on your edgeflipping direction). This big jump is animated by wobbly causing some "shiver" effect which looks pretty weird. This problem is normally obscured by rotate's flip time, but becomes visible pretty easily if you set this setting to a low value (such as 20 ms). Unfortunately I don't have a solution off-hand :-( There's one more problem which can be seen best on this video (from a digital camera only, I can't afford using xvidcap for the whole desktop): http://kfe.fjfi.cvut.cz/~potocek/work/storage/move.mov Note the lower left edge moving sometimes opposite to what I do with the upper left edge. When one has a window snapped to the top screen border, one can manage to move it still upwards by dragging center of its title bar downwards for the same reason, but this is a bit harder to simulate. This came too with the commit mentioned above. - Vasek ___ compiz mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] A few more bugs...
I have found one file I prepared for sending here when discussing Shade issues but never have done so. It documents the following problem: when one makes a window shade (both using double click or key binding), its "border windows" remain there and can be used to resize it. Moreover, during this the right window sometimes disappears and doesn't show again after unshading, so the window cannot be resized using its right border until it is resized using the left border. This happens to the bottom border as well. Here's the capture: http://kfe.fjfi.cvut.cz/~potocek/work/storage/shade.mpeg - Vasek ___ compiz mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/compiz
