Re: [compiz] The object framework branch
Hello! Maybe this is bad question, but talking about the promising projects, what's the current state of input transformations? In my opinion, these would be definitely attractive to revisit! I'm completely off the picture by now but I remember the Compiz developers were still waiting for some changes to the X system to allow this. However, I have had an idea: As far as I understand, the GL_EXT_texture_from_pixmap extension was David Reveman's idea after all, wasn't it? So it could be said it was implemented in the drivers for the purpose of simplifying composite managers, especially Compiz. Couldn't the Compiz developers similarly implement the input transformations backend as an extension to X, or is it impossible this way? Best regards and good luck with all the new effort, VaĊĦek P. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] fonts unreadable on resize
Thank you, at least for me, this helped. I didn't blame nvidia because I had two computers with the same nvidia driver version and resizeinfo worked well on one of them. V. Dennis Kasprzyk napsal(a): > Am Freitag, 28. Dezember 2007 23:51:41 schrieb Bill Moseley: >> I have the "Resize info" feature enabled on my desktop and on my >> laptop both running Gutsy. >> >> on the desktop the fonts are impossible to read: >> >> http://hank.org/resize.png >> >> but are very clear on the laptop. >> >> And tips to fix? > > Do you have a nvidia card in your desktop? > > I had the same problem with the 100.x.x driver and it's gone with the 169.x > driver. > > Dennis > > ___ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz > ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] fonts unreadable on resize
Sorry, maybe I don't understand you... I'm experiencing exactly the same on a Fedora-equipped laptop with horizontal RGB subpixel order. And if I'm right with my guess, I can see the issue with a ~100 line program which does not use cairo at all. V. Travis Watkins napsal: > On Dec 28, 2007 4:51 PM, Bill Moseley <[EMAIL PROTECTED]> wrote: >> I have the "Resize info" feature enabled on my desktop and on my >> laptop both running Gutsy. >> >> on the desktop the fonts are impossible to read: >> >> http://hank.org/resize.png >> >> but are very clear on the laptop. >> >> And tips to fix? >> >> > > You have a broken cairo (and are most likely using Ubuntu or Mandriva) > and cannot use VBGR subpixel order. > ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] fonts unreadable on resize
> About your last question, looks like this bunch of lines do it: > http://cgit.compiz-fusion.org/fusion/plugins-main/tree/src/resizeinfo/resizeinfo.c#n184 NB: this means - the font choice is done in the plugin and - if you want to change the font, you'll have to recompile the plugin from its source, there's no config option for it. V. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] fonts unreadable on resize
Hello, be sure you had a look really at the first moment the resizeinfo plugin is used after it was *loaded* (you can unload and re-load it if you want to try). In subsequent resize operations, the same rectangle is re-used, so its content is bad from the beginning. Notice the double "x" in your picture - I'm quite sure it stems from this redrawing issue. About your last question, looks like this bunch of lines do it: http://cgit.compiz-fusion.org/fusion/plugins-main/tree/src/resizeinfo/resizeinfo.c#n184 PS. Hope you don't mind sending this back to the list, I forgot about the "Reply to all" rule in my first mail. Vasek Bill Moseley napsal: > On Sat, Dec 29, 2007 at 12:39:25AM +0100, Vasek Potocek wrote: >> Hello, >> >> I have noticed this also, but have completely forgot since. I found this >> was a problem with unclear understanding of filling with a >> (semi-)transparent color in the X library: imagine you want to clear your >> semi-transparent window for subsequent drawing. So you use some fill >> function to fill it with a semi-transparent color. Now various X versions >> behave in either of the following two ways: >> - setting all the influenced pixels to this color, >> - blending the color to the background. >> Newer versions seem to do the latter, but I have no real comparison. It can >> equally well be the difference of x86 / x86_64 or anything. The problem is >> that we need the former behaviour, but have not much ways to do so. >> >> [Your problem is that any time the text is to be changed, the latter >> happens instead of the former and the new text is drawn over the old, so >> that it quickly cummulates into solid black.] > > I will note that the fonts are un-readable the instant they appear > -- before any resizing occurs. But, I'm not sure if that means what > you describe is happening my my case or not. > > Any idea how Compiz selects the font for that the Resize Info plugin? ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] commit a50d2f9e0f66f445338eb5ad7361b48d48446b29 broke compiz for me
dragoran napsal(a): Sam Spilsbury wrote: How are you launching compiz? If you are using GConf, then you need to launch compiz like this from now on : $ENVIRONMENT_ARGS compiz --replace --sm-disable --indirect-rendering glib gconf& If I start it using this command it works. but when I let gnome-session start it it doesn't. but this looks wrong anywhy... when a plugin depends on some other plugin compiz core should load the plugin for it and not rely on the user to do it. Yes, gnome-session is not prepared for this change. The attached patch to /usr/bin/gnome-wm seems to work here (I have tried it only once now, though). --- /usr/bin/gnome-wm-zal 2007-05-27 13:17:01.0 +0200 +++ /usr/bin/gnome-wm 2007-05-27 13:17:42.0 +0200 @@ -84,10 +84,11 @@ WINDOW_MANAGER=xterm fi -# Now create options OPT1, OPT2 and OPT3 based on the windowmanager used +# Now create options OPT1, OPT2, OPT3 and OPT4 based on the windowmanager used OPT1= OPT2= OPT3= +OPT4= if [ ! -z "$SMID" ] ; then case `basename $WINDOW_MANAGER` in sawfish|sawmill|metacity) @@ -120,10 +121,11 @@ case `basename $WINDOW_MANAGER` in compiz) gtk-window-decorator & -OPT3=gconf +OPT3=glib +OPT4=gconf ;; esac -exec $WINDOW_MANAGER $OPT1 $OPT2 $OPT3 +exec $WINDOW_MANAGER $OPT1 $OPT2 $OPT3 $OPT4 echo "ERROR: No window manager could run!" ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] compiz segfaults on starting second X server / suspend to ram
> Hello, > when I start a second X server or when I suspend (and resume) to ram > compiz crashes. > I tryed to debug this but its impossible to run gdb on compiz (=freeze). > This happens with current git, but If I remember correctly not with > 0.3.6 (and git versions < 0.5.0 but I don't know when it started to happen). > any ideas? It is possible to debug compiz using gdb, you just can't run gdb in a terminal drawn by compiz. The simplest way is to run it remotely through ssh. If you don't have another computer at your disposal, it's still possible to run gdb+compiz on another VT, but you'll need to utilize the kernel's "Magic SysRq key" to escape from the freeze (to get back to the console). You can find more info on both ways (plus one more which doesn't seem to be much reliable) on these links: http://forum.compiz.org/viewtopic.php?p=111 http://www.ubaight.com/pipermail/compcomm/2007-May/000639.html [Thanks to the author of the latter post! I haven't heard about the key combination before.] I'd add that the SysRq key combinations may not be available by default, it depends on kernel compiling configuration and it can be turned on/off in addition. I don't know the various kernels, see your kernel documentation for details. For example, on my Fedora Core 6, the support is compiled in, but must be turned on as described in /usr/share/doc/kernel-doc-2.6.20/Documentation/sysrq.txt. And the situation is still a bit more tricky with nVidia because of its "VT-switching bug" (I may be wrong here), I solved this by switching to the X VT very very fast after the run command :-) ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Transparent cube
Vasek Potocek napsal(a): Dennis Kasprzyk napsal: Am Samstag, 28. April 2007 15:35 schrieb Vasek Potocek: Hello, is there any way of utilizing OpenGL's depth test instead of the paint order? If I understand it well, the aim here is to get it looking _like_ with depth test. I understand that shifting windows by an "infinitesimal" offset in the z direction would lead to various problems, but isn't is possible to persuade OpenGL somehow to use different coordinate for the depth test than for the perspective projection? (It would require a little bit more math than I outlined here, but should be possible.) V. For transparency effects you can't use a depth test, you have to paint the whole screen from back to front. Dennis I'm sorry, I really forgot about the problem with transparency x depth test. However, I still think this is soluble: what about using the cubeCheckFTB function for deciding which glBlendFunc to use? Normally we'd need to multiply the color drawn both by SRC_ALPHA and ONE_MINUS_DST_ALPHA, which is not possible well enough, but thanks to compiz' alpha-premultiply demand (fix me if it's not so), we could just choose glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA); (as it is done now) when drawing in front of all and glBlendFunc(GL_ONE_MINUS_DST_ALPHA, GL_ONE); if drawing behind all. No other situation should arise in cube + 3D with BTF (and no other situation would be soluble at all even the original way, however). Sorry, this was inexact, forget it, please. Of course, the current code draws windows in a 1-2-3-6-5-4 order or so. What is insoluble in both are more complex 3D effects which could cause windows for example intersect. I hacked together a little demo showing this, see the attachment and comments in it. One problem I can see is this needs the support for alpha bitplanes, which is not so automatic, could we rely on it in Linux implementations? V. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Transparent cube
Dennis Kasprzyk napsal:
Am Samstag, 28. April 2007 15:35 schrieb Vasek Potocek:
Hello,
is there any way of utilizing OpenGL's depth test instead of the paint
order? If I understand it well, the aim here is to get it looking _like_
with depth test. I understand that shifting windows by an "infinitesimal"
offset in the z direction would lead to various problems, but isn't is
possible to persuade OpenGL somehow to use different coordinate for the
depth test than for the perspective projection? (It would require a little
bit more math than I outlined here, but should be possible.)
V.
For transparency effects you can't use a depth test, you have to paint the
whole screen from back to front.
Dennis
I'm sorry, I really forgot about the problem with transparency x depth test. However, I still think this is soluble:
what about using the cubeCheckFTB function for deciding which glBlendFunc to use? Normally we'd need to multiply the
color drawn both by SRC_ALPHA and ONE_MINUS_DST_ALPHA, which is not possible well enough, but thanks to compiz'
alpha-premultiply demand (fix me if it's not so), we could just choose glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA); (as
it is done now) when drawing in front of all and glBlendFunc(GL_ONE_MINUS_DST_ALPHA, GL_ONE); if drawing behind all. No
other situation should arise in cube + 3D with BTF (and no other situation would be soluble at all even the original
way, however).
I hacked together a little demo showing this, see the attachment and comments
in it.
One problem I can see is this needs the support for alpha bitplanes, which is not so automatic, could we rely on it in
Linux implementations?
V.
/* The base is taken from NeHe (see copyright notice below),
* for the important part, look for the drawGLScene function.
*
* You can pause the animation using space and quit the program by
* q or Escape. You can also try adjusting the individual colours in the
* source to test various situations, but keep them alpha-premultiplied.
*/
/*
* This code was created by Jeff Molofee '99
* (ported to Linux/GLX by Mihael Vrbanec '00)
*
* If you've found this code useful, please let me know.
*
* Visit Jeff at http://nehe.gamedev.net/
*
* or for port-specific comments, questions, bugreports etc.
* email to [EMAIL PROTECTED]
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define Pi 3.14159265358979323846
typedef struct {
Display *dpy;
int screen;
Window win;
GLXContext ctx;
XSetWindowAttributes attr;
int x, y;
unsigned int width, height;
unsigned int depth;
} GLWindow;
/* attributes for a single buffered visual in RGBA format with at least
* 4 bits per color and a 16 bit depth buffer */
static int attrListSgl[] = {
GLX_RGBA,
GLX_RED_SIZE, 4,
GLX_GREEN_SIZE, 4,
GLX_BLUE_SIZE, 4,
GLX_ALPHA_SIZE, 4,
GLX_DEPTH_SIZE, 16,
None};
/* attributes for a double buffered visual in RGBA format with at least
* 4 bits per color and a 16 bit depth buffer */
static int attrListDbl[] = {
GLX_RGBA, GLX_DOUBLEBUFFER,
GLX_RED_SIZE, 4,
GLX_GREEN_SIZE, 4,
GLX_BLUE_SIZE, 4,
GLX_ALPHA_SIZE, 4,
GLX_DEPTH_SIZE, 16,
None };
GLWindow GLWin;
GLfloat z = -5.0;
int stop = 0;
void resizeGLScene(unsigned int width, unsigned int height) {
if(height==0) height = 1;
glViewport(0, 0, width, height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0f, (GLfloat)width / (GLfloat)height, 0.1f, 100.0f);
glMatrixMode(GL_MODELVIEW);
}
int initGL(GLvoid) {
glShadeModel(GL_SMOOTH);
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glEnable(GL_BLEND);
glDisable(GL_DEPTH_TEST);
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);
/* we use resizeGLScene once to set up our initial perspective */
resizeGLScene(GLWin.width, GLWin.height);
glFlush();
return True;
}
int drawGLScene(GLvoid) {
static float t = 0, x;
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
glTranslatef(0.0f, 0.0f, z);
x = sin(t);
if(x<0) /* This is a simple check supplying cubeCheckFTB */
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
else
glBlendFunc(GL_ONE_MINUS_DST_ALPHA, GL_ONE);
glTranslatef(x, 0.0, 0.0);
glBegin(GL_QUADS);
glColor4f(0.5, 0.0, 0.0, 0.5);
glNormal3f(1.0, 0.0, 0.0);
glVertex3f(0.0, 1.0, 2.0);
glVertex3f(0.0, 1.0, -1.0);
glVertex3f(0.0, -1.0, -1.0);
glVertex3f(0.0, -1.0, 2.0);
glEnd();
x += 0.1;
if(x<0)
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
else
glBlendFunc(GL_ONE_MINUS_DST_ALPHA, GL_ONE);
glTranslatef(0.1, 0.0, 0.0);
glBegin(GL_QUADS);
glColor4f(0.9, 0.9, 0.9, 0.9);
glVertex3f(0.0, 1.0, 2.0);
glVertex3f(0.0, 1.0, -1.0);
glVertex3f(0.0, -1.0, -1.0);
glVertex3f(0.0, -1.0, 2.0);
glEnd();
x += 0.1;
if(x<0)
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
else
glBlendFunc(GL_ONE_MINUS_DST_ALPHA, GL_ONE);
g
Re: [compiz] Re: [PATCH] Transparent cube
Hello, is there any way of utilizing OpenGL's depth test instead of the paint order? If I understand it well, the aim here is to get it looking _like_ with depth test. I understand that shifting windows by an "infinitesimal" offset in the z direction would lead to various problems, but isn't is possible to persuade OpenGL somehow to use different coordinate for the depth test than for the perspective projection? (It would require a little bit more math than I outlined here, but should be possible.) V. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Fix unredirect fullscreen windows
David Reveman napsal: On Mon, 2007-04-23 at 18:04 -0700, James Jones wrote: While trying to reproduce an error with input handling and unredirect fullscreen windows, I noticed the option didn't work at all in compiz master. This patch gets it working again. Yes, I guess that's been broken since we added the new occlusion detection code. Thanks, - David Hello, am I the only one having the following problem with unredirect_...? The fullscreen windows (think of xscreensaver) very often remain visible after "unmapping" and only the mouse cursor changes according to what should be where on screen. I thought invoking cube rotation or so could help (redrawing all the screen), but it does not, I need to launch and kill xscreensaver again hoping that time it will succeed. This, obviously, prevents me from using this option. I hoped this patch was meant for that issue, but it doesn't help here... To be exact, I have seen this only with xscreensaver, but since I am not a gamer, I have only that and mplayer to test. However, this is nothing serious for me, it can be caused by any part of the chain, and if it is rare, I don't want anyone to spend his time hunting this bug :-) - Vasek [nVidia GeForce FX5200] ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] White Boarders in AIGLX on non-decorated window types
David Reveman napsal: On Wed, 2007-04-18 at 19:25 +0200, Vasek Potocek wrote: Oops, I haven't finished my e-mail... The reason why I posted just another workaround is that I consider it "less workaround" than the former fix (supposing this really was the same problem) and that it helps in more situations (like in GTK+ drag-drop, RYX said he had problems with this). But it's really hacky, it should apply depending on whether the described circumstances really happen and so, but as I said, it's temporary and only for the interested. I use it in my local clone and I actually haven't had many reasons to make it cleaner. OK, so a bug in the nvidia driver is causing this problem then. If the change you had in your previous mail is working as a way to avoid the problem, I'll be able to modify the code and make it work without having it do anything wrong. Does the attached patch fix your problem? - David Yes, it works fine. Thank you very much for making this a proper patch, I am feeling guilty for not doing it myself :-( but my code wouldn't be so good anyhow. Thank you for paying attention to the Shade issue as well! But the people having the decoration problem should answer this question! I didn't want to turn the thread's topic to anything else. - Vasek ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] White Boarders in AIGLX on non-decorated window types
Oops, I haven't finished my e-mail... The reason why I posted just another workaround is that I consider it "less workaround" than the former fix (supposing this really was the same problem) and that it helps in more situations (like in GTK+ drag-drop, RYX said he had problems with this). But it's really hacky, it should apply depending on whether the described circumstances really happen and so, but as I said, it's temporary and only for the interested. I use it in my local clone and I actually haven't had many reasons to make it cleaner. OK, so a bug in the nvidia driver is causing this problem then. If the change you had in your previous mail is working as a way to avoid the problem, I'll be able to modify the code and make it work without having it do anything wrong. - David I honestly can't say for sure, it works reliably for the p-o-t pixmaps generally, but I didn't have the particular problem with the decoration. My "normal" windows sized 32x32 or 128x128 or even 8x64 or anything like this were painted white (accompanied by a flood of "pixmap ... can't be bound to texture"). Sorry for splitting my mail so stupidly, this is how it started: I haven't seen this problem nor searched the internet for more info on this topic, so I'm sorry if I'm answering too > impetuously. But talking about restricting texture sizes, this looks to me similar to a problem of some NVIDIA cards > (say: of my one) I have examined some time ago: when the fbConfig doesn't have its GLX_TEXTURE_2D_BIT_EXT set in > GLX_BIND_TO_TEXTURE_TARGETS_EXT, the power-of-two textures cause a BadMatch error in glXCreatePixmap instead of being treated as rectangle ones as the GLX_EXT_tfp specification states. Couldn't this be related? - Vasek ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] White Boarders in AIGLX on non-decorated window types
Oops, I haven't finished my e-mail... The reason why I posted just another workaround is that I consider it "less workaround" than the former fix (supposing this really was the same problem) and that it helps in more situations (like in GTK+ drag-drop, RYX said he had problems with this). But it's really hacky, it should apply depending on whether the described circumstances really happen and so, but as I said, it's temporary and only for the interested. I use it in my local clone and I actually haven't had many reasons to make it cleaner. V. David Reveman napsal: On Wed, 2007-04-18 at 15:45 +0800, Sam Spilsbury wrote: How is it a workaround? It fixes the problem... It's pretty obvious if you look at the code. It avoids creating pixmaps with certain widths even though that should work perfectly fine. On 4/18/07, David Reveman <[EMAIL PROTECTED]> wrote: On Fri, 2007-04-13 at 21:40 +0800, Sam Spilsbury wrote: > A patch was submitted to the ML a while ago that cured the problem > with white boarders in Gtk-Window-Decorator. Can this patch be > commited or be a at least fixed up to work with AIGLX? What patch is that? In case you're talking about this patch: http://gandalfn.club.fr/ubuntu/compiz-patch/90-fix-no-border-window-shadow.patch That patch has not been committed because it's not a fix. It's a workaround for an issue that no one have been able to track down yet afaik. - David - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] White Boarders in AIGLX on non-decorated window types
I haven't seen this problem nor searched the internet for more info on this topic, so I'm sorry if I'm answering too
impetuously. But talking about restricting texture sizes, this looks to me similar to a problem of some NVIDIA cards
(say: of my one) I have examined some time ago: when the fbConfig doesn't have its GLX_TEXTURE_2D_BIT_EXT set in
GLX_BIND_TO_TEXTURE_TARGETS_EXT, the power-of-two textures cause a BadMatch error in glXCreatePixmap instead of being
treated as rectangle ones as the GLX_EXT_tfp specification states. Couldn't this be related?
Mr. James Jones of NVIDIA said this will be fixed in the driver, so I didn't want to post any temporary workarounds
here. However, if anybody is interested, it's quite simple:
--- a/src/texture.c
+++ b/src/texture.c
@@ -236,6 +236,7 @@ bindPixmapToTexture (CompScreen *screen,
int attribs[] = {
GLX_TEXTURE_FORMAT_EXT, config->textureFormat,
GLX_MIPMAP_TEXTURE_EXT, config->mipmap,
+ GLX_TEXTURE_TARGET_EXT, GLX_TEXTURE_RECTANGLE_EXT,
None
};
- Vasek
David Reveman napsal:
On Wed, 2007-04-18 at 15:45 +0800, Sam Spilsbury wrote:
How is it a workaround? It fixes the problem...
It's pretty obvious if you look at the code. It avoids creating pixmaps
with certain widths even though that should work perfectly fine.
On 4/18/07, David Reveman <[EMAIL PROTECTED]> wrote:
On Fri, 2007-04-13 at 21:40 +0800, Sam Spilsbury wrote:
> A patch was submitted to the ML a while ago that cured the
problem
> with white boarders in Gtk-Window-Decorator. Can this patch
be
> commited or be a at least fixed up to work with AIGLX?
What patch is that? In case you're talking about this patch:
http://gandalfn.club.fr/ubuntu/compiz-patch/90-fix-no-border-window-shadow.patch
That patch has not been committed because it's not a fix. It's
a
workaround for an issue that no one have been able to track
down yet
afaik.
- David
- David
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
___
compiz mailing list
compiz@lists.freedesktop.org
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
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] [PATCH] Fade vs. Animation conflict resolution
Hello, according to the fade description in compiz.schemas, this plugin is supposed to fade windows _only_ when being mapped/unmapped, isn't it? Actually, its "other effects" are quite annoying for me in combination with bs or widget plugins, fade is making them act much slowly than they were designed to. (On the other hand, I find very useful the fading when a window becomes irresponsive, which is holding me from switching from fade to animation.) Unfortunately, in the current fade architecture, solving this seems nearly impossible, or does anybody have any ideas? Vasek Hi, Here is a simple patch that adds an option to the Fade plugin to enable/disable fading on minimize/open/close window events. This option is on by default but can be disabled to avoid conflicts with the Animation plugin. Fading on other stuff (fade during nonresponding app. desaturation, during switcher, and visual bell) shouldn't be affected (which is the main point of this patch). Regards, Erkin ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Nvidia performance bug and vterm switching bug
I have turned on the DEBUG macro and found my terminal is filled by a flood of messages like this: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 Minor opcode of failed request: 16 Resource id in failed request: 0x20de every now and then when direct rendering is used. However, I can't tell where such message comes from, because the minor opcode of 16 doesn't mean anything useful: X_GLXVendorPrivate. Edit: it comes from bindTexImage call in enableTexture function, texture.c, line 358. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Nvidia performance bug and vterm switching bug
This has been a long problem with Compiz that NVIDIA never fixed, intermittent performance problems such as hick ups; the problem is easily reproducible moving the cursor while opening programs such as Firefox or Evolution. Until Compiz 0.3.4 this bug was fixed setting the __GL_YIELD environment variable to "NOTHING" in Compiz environment. the only thing that this changes (and is supposed to change) is to make compiz responsive under high cpu load. Since Compiz 0.3.6 setting the __GL_YIELD environment variable to "NOTHING" is not enough, but launching Compiz WITHOUT "--unredirect-rendering" is also needed to fix this. So whats the problem using direct-rendering? using direct-rendering triggers the NVIDIA vterm switching bug, that makes the screen keep black on vterm switching. If one clicks at the black screen, a hard reboot is needed; the only solution is to kill X and start it again. Turn of sync to vblank this might be causing this. Also, for some people like me, using --indirect-rendering gives better performance than using direct rendering. no its not! if you use indirect rendering on nvidia the _GL_YIELD env variable will gets ignored and the system will be almost unuseable under high load. I can confirm the problem, although it does not happen regularly for me -- -- sometimes compiz crashes with a SEGFAULT instead and sometimes all continues to work normally after a few VT switches. For that reason, I'm using --indirect-rendering by default and have few experience with the opposite. I have turned on the DEBUG macro and found my terminal is filled by a flood of messages like this: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 Minor opcode of failed request: 16 Resource id in failed request: 0x20de every now and then when direct rendering is used. However, I can't tell where such message comes from, because the minor opcode of 16 doesn't mean anything useful: X_GLXVendorPrivate. I think this can very well cause the slowdown, but the VT switching bug probably not. Note: Turning off Sync to VBlank seems only to attenuate the latter. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] A few more bugs...
2) This one should be easily reproducible: - Shade one window (W1) on a viewport. - Click another window (W2) to move focus on it. - Unshade W1 by double-clicking its title bar. - Click W2 again - it gets focus, but graphically it still looks like W1 has it. Repeated clicking on W2 doesn't help. Hm, I can't reproduce this but I fixed a shading focus issue just before I read this and it might very well be related to this issue. Please try again with the latest code and let me know if it's still broken. Yes, it remains here... In git, I found that you have solved the mentioned issue in event.c, so I added some printf's there and here is what I get: (W2 clicked) FocusIn: 0x8876fd8 ID: 03E09243 Active: 03E07C26 FocusIn: 0x8876fd8 ID: 03E09243 Active: 03E09243 (W1 title bar double-clicked) FocusIn: 0x8876978 ID: 03E08508 Active: 03E09243 FocusIn: 0x8876978 ID: 03E08508 Active: 03E08508 FocusIn: 0x8944108 Not managed (W2 clicked) FocusIn: 0x8876fd8 ID: 03E09243 Active: 03E08508 FocusIn: 0x8876fd8 ID: 03E09243 Active: 03E09243 (W1 title bar double-clicked) FocusIn: 0x8944108 Not managed FocusIn: 0x8944108 Not managed (W2 clicked) FocusIn: 0x8876fd8 ID: 03E09243 Active: 03E09243 FocusIn: 0x8876fd8 ID: 03E09243 Active: 03E09243 So, clicking the shaded window does not change d->activeWindow and compiz thinks the last window is still focused. I don't know all the code about, first of all, I don't know who then gives focus to W1, but I believe you will understand well what is going on here. V. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] A few more bugs...
Hello, I found a couple bugs concerning my favourite Shade/Unshade function. 1) Sometimes the shaded window gets more space than it should and, of course, nobody takes care about it, so everything drawn on this space remains here. If I move a decorated window along, its shadow cummulates quickly to full black here. Unfortunately, I don't know any reliable way how to reproduce this. (But it seems that Mozilla Firefox & Thunderbird tend to show this quite often.) May these screenshots be of some help... http://kfe.fjfi.cvut.cz/~potocek/work/storage/shade.png http://kfe.fjfi.cvut.cz/~potocek/work/storage/shade2.png (after minimizing the shaded window) http://kfe.fjfi.cvut.cz/~potocek/work/storage/shade3.png (this have I found during typing this message) 2) This one should be easily reproducible: - Shade one window (W1) on a viewport. - Click another window (W2) to move focus on it. - Unshade W1 by double-clicking its title bar. - Click W2 again - it gets focus, but graphically it still looks like W1 has it. Repeated clicking on W2 doesn't help. Sorry I have been always complaining, I don't mean it bad :-/ Vasek ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Actions restrictions
On Tue, 2007-03-06 at 11:39 +0100, Cedric wrote:
Here a patch to add actions restrictions to core.
What it do:
- add restrictActionsMask to CompWindow.
- add constrainWindowActions() returning "filtered" window actions
- add changeWindowActions() taking care of restrictActionsMask
I have do some testing with winrules, seems to works well.
David, maybe you have a better idea?
This only allows one plugin to restrict actions. We want to allow any
number of plugins to restrict available actions.
I quickly added a getAllowedActionsForWindow screen function that should
take care of this. Wrap getAllowedActionsForWindow and do something like
this in your plugin implementation of that function:
static unsigned int
pluginGetOutputExtentsForWindow (CompWindow *w)
{
unsigned int actions;
PLUGIN_WINDOW (w);
UNWRAP (ps, w->screen, getAllowedActionsForWindow);
actions = (*w->screen->getAllowedActionsForWindow) (w);
WRAP (ps, w->screen, getAllowedActionsForWindow,
pluginGetAllowedActionsForWindow);
return actions & pluginAllowedActions;
}
and call recalcWindowActions whenever you want it updated.
Any problems, just let me know.
- David
There is a little but a bit funny typing error - it is necessary to delete the tilde on line 696 of window.c, otherwise
all common actions will be taken from all the windows.
Vasek
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] A couple of bugs...
2. Resizing a KDE-Window (independently of the window-decorator -- just a kde window like konqueror) doesn't work properly. When grabbing one edge all other edges change position. Only when you use the bottom right corner it works as expected. Strangely GNOME/Gtk windows work as expected. I'd add to this point that this is not only KDE-specific, I can reliably reproduce the described behaviour with xterm window. I have once worked it around using XGetWindowAttributes instead of rd->w->attrib in each call of resizeUpdateWindowSize, but this is both too ugly to be really suggested and still not 100% reliable (the bottom edge tends to vary +-1 line). There is still another problem that worries me - sometimes the Shade/Unshade function causes the window to jump vertically, about randomly. The window ends up at approx. half its height after Shade and a little above or under its original position after Unshade, but sometimes half above the top of screen, too. This is not restricted to any types of windows, but occasional in the sense that sometimes it just does happen and sometimes it doesn't on the same window. I didn't investigate this much, but I have suspicion it's related to whether a window is in more or less "stable" position, meaning whether it wobbles a bit or not when its caption is clicked. I'm sorry if this has been discussed here or somewhere in the past, I don't know it. Vasek ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Blur bugs and slowdown :(
Hello! I don't expect myself to be of much use on this list, I have joined mainly to see how it all proceeds... but I have experienced the same problem as Mr. Bellegarde. I noticed the artifacts copy some area of screen underneath it. It looks like twice enlarged with the center in bottom-left corner of screen. You can see what I'm talking about here: http://kfe.fjfi.cvut.cz/~potocek/work/blur-problem.png Of course, it happens only with 4xBilinear, too. Yes, and I can't see GL_ARB_texture_non_power_of_two in glxinfo. I'm using nVidia driver v. 9746 on a FX5200. I hope this could be a bit helpful. Vasek I now use blur plugin thanx to window matching feature, thanx David ;) I have some bugs: http://hibbert.univ-lille3.fr/~cbellegarde/blur_4xbilinear_bug.png Here, i have some artefacts bugs with 4xbilinear. This blur mode is fast! May be a Nvidia drivers bug... Thanks to both of you for your feedback. I found two issues in the 4xbilinear code that likely caused the drawing artifacts. Please check with the latest code and let me know if it's still causing issues. - David It works fine now, the problem has been solved. Thank you! ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
