Re: [compiz] Wobbly jerkyness
Hello
On May 2, 2007 02:50:30 pm David Reveman wrote:
> On Sun, 2007-04-29 at 17:54 +0800, Sam Spilsbury wrote:
> > About a month ago, David made a commit to wobbly to the spring engine
> > which has introduced some bugs. They are hard to explain so bear with
> > me.
> >
> > In a sense, the wobbly plugin does not seem as smooth as it used to be
> > and the windows jerk all over the place. For example, I sometimes
> > notice that when I move a large window (around 2/3 of the size of the
> > desktop window), If I moved it down, the top of the window would jerk
> > up then come down quickly. If you want me to explain further then let
> > me know
>
> I didn't change anything in the wobbly plugin, I changed how the move
> plugin works.
>
> Eventually, I'll make it possible to not have the move plugin update the
> window attributes in real-time and I can guarantee that performance will
> be at least as good as before I did these changes to the move plugin.
> However, before I can make this possible we need to improve the way
> window animations are performed. What the move plugin was doing before
> was wrong and I'm not going to change back to that.
>
Would this also resolve the problems the Xserver has wrt evicting pixmaps and
EXA/XAA? For r300 users, we have to add in a ugly hack
specifically:
xorg-x11-server-1.1.1-offscreen-pixmaps.patch
Afaik, There's no solution proposed (?) yet.
I originally look at this and hit a problem:
/* Check if XAA is loaded */
if (xf86LoaderCheckSymbol("XAAEvictPixmaps")) {
XAAInfoRecPtr infoRec;
infoRec = GET_XAAINFORECPTR_FROM_SCREEN(glxPixmap->pDraw->pScreen);
if (InfoRec) {
/* When the GLX_EXT_texture_from_pixmap is used, as it's
* implemented here, we want to pull pixmap out of video
memory
* and into host memory. */
static int evictedPixmaps;
if (!evictedPixmaps) {
XAAEvictPixmaps();
evictedPixmaps = TRUE;
}
}
}
This snip of code above, wasn't the right solution to be doing inside the glx,
The goal was to see if a specific screen has EXA or XAA (im told you can have
different accelerations for each screen).
I have to keep using the above mentioned patch in order to have a usable
compiz otherwise, resizing windows and other functions make compiz totally
unusable for radeon users (with XAA).
I note, this is using AIGLX, so I don't know the behavour of this with Xgl.
Thanks,
Shawn.
>
> - David
>
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: Plugin Interface for Decoations
Hello On May 2, 2007 03:50:50 pm David Reveman wrote: > On Mon, 2007-04-30 at 17:24 +0200, Patrick Niklaus wrote: > > I realized some major problems with this approach. To give you a > > better idea of what I'm actually talking about, take a look at this > > schema: > > http://media.beryl-project.org/Decoration-Schema.png > > > > As you can see KWD, GWD and Emerald would run in the same > > applications, as plugins. > > This might cause problems because the main loops of Qt and Gtk are > > conflicting here, which was actually one of the reasons why the > > decorator was not a own plugin in compiz. > > > > Another problem is the settings backend. To integrate into the desktop > > each plugin uses its own backend. For example the emerald plugin uses > > ini/gkey files + libemeraldengine but GWD gconf + metacity functions. > > So basically we would end up with a complete window decorator, ported > > to a plugin, which is not really what I had in mind. > > > > An alternative would be, remaining the current structure of having > > several decorator running as an own application and expand emerald to > > an highly-customizeable and extentable decorator, which relies on > > plugin architecture. The main goal of that decorator would be to > > provide an independently theme and other rather experimental things > > like animations. > > > > This architecture is shown in this schema: > > http://media.beryl-project.org/Decoration-Schema2.png > > > > You're welcome to improve emerald, rewrite it or write a completely new > decorator, I'm definitely not going to stand in the way of that. > However, I suggest that you avoid duplicating work when not necessary > and avoid creating alternatives to existing solutions. > > libdecoration contains code that is used by all decorators. If you find > some code that makes sense for more than one decorator, it likely makes > sense to put that code in libdecoration. > > What's missing in current decorators? The following is what I think is > missing and how it's most properly fixed. One thing that the old original Emerald window decorator did was support button effects, some of these effects like the glow effect. I don't know if Emerald-2 or compiz deal with specific button effects themselves? > - David > Shawn. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Option for activation behaviour on window close
On Mon, 2007-04-30 at 11:05 +0200, Danny Baumann wrote: > Hi, > > please find attached a patch that makes the behaviour of window > activation when a window is closed optional. > Currently, always the last active window is activated. Sometimes this > might not be the desired behaviour, but users (like me ;-) ) would like > the window under the pointer to be activated. This patch adds the latter > behaviour as an option while still keeping the former behaviour as > default. > > Questions / concerns / objections / opinions anyone? Is there any reason someone using click-to-focus would want this? Is there any reason someone not using click-to-focus wouldn't want this? - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] gtk-window-decorator Wnck warnings
On Mon, 2007-04-30 at 01:22 -0500, Erkin Bahceci wrote: > Hi, > > I'm getting a lot of warnings like this one: > (gtk-window-decorator:8442): Wnck-WARNING **: Unhandled action type (nil) > > Does anyone else see these warnings or know what causes these? That warning is caused by compiz setting the new ACTION_ABOVE hint on windows and old versions of libwnck doesn't recognize that hint. It's harmless and if you upgrade to a newer version of libwnck (I think you need the svn version) it will disappear. That libwnck spits out a warning just because it doesn't recognize an action type is sort of bug. > > Also, it seems that this "lost textures" bug > https://bugs.freedesktop.org/show_bug.cgi?id=10789 > usually happens only when these warnings are spitted out, so the bug > is probably related to these wnck warnings. I haven't looked at the "lost textures" bug but I can guarantee that it's not related to this libwnck warning. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: Plugin Interface for Decoations
On Mon, 2007-04-30 at 17:24 +0200, Patrick Niklaus wrote: > I realized some major problems with this approach. To give you a > better idea of what I'm actually talking about, take a look at this > schema: > http://media.beryl-project.org/Decoration-Schema.png > > As you can see KWD, GWD and Emerald would run in the same > applications, as plugins. > This might cause problems because the main loops of Qt and Gtk are > conflicting here, which was actually one of the reasons why the > decorator was not a own plugin in compiz. > > Another problem is the settings backend. To integrate into the desktop > each plugin uses its own backend. For example the emerald plugin uses > ini/gkey files + libemeraldengine but GWD gconf + metacity functions. > So basically we would end up with a complete window decorator, ported > to a plugin, which is not really what I had in mind. > > An alternative would be, remaining the current structure of having > several decorator running as an own application and expand emerald to > an highly-customizeable and extentable decorator, which relies on > plugin architecture. The main goal of that decorator would be to > provide an independently theme and other rather experimental things > like animations. > > This architecture is shown in this schema: > http://media.beryl-project.org/Decoration-Schema2.png > > I'm not really sure which one would fit our needs best here (or if > there would be other solutions), so it would be the best if we could > discuss that here. > > Regrads, > Patrick > > 2007/4/29, Patrick Niklaus <[EMAIL PROTECTED]>: > > Hi, > > > > this email is basically the result of a small discussion which made me > > think what the real end-goal of my work on Emerald-2 would be. Since > > Emerald has already a extensible system (Engines) I thought about > > giving the engines wider access, so that they are more like plugins. > > However the first thing needed is a nice plugin API. The base for that > > is the new settings backend of Emerald-2. Settings backend might not > > be the right word here, since it handles a lot more, it could also be > > called engines backend. (=> libemeraldengine) > > > > The next step is, taking GWD (which has a proper usage of > > libdecoration), port it to that system and also port most of Emerald > > features to it. This includes pixmap buttons and usage of the button > > interface for libdecoation, which will described in detail in another > > mail. > > > > Basically we would end up with a better Emerald, working name Emerald-2. > > Now, if we got that working properly we need to think about what will > > be moved to a plugin and what will stay in core. At this point we also > > need an exact definition of the plugin API. A first general definition > > can be found below. > > > > It would be really nice if I could get some feedback or suggestions on my > > plans. > > > > BTW. Please do not start a flame war because of the working name, it > > will be probably changed and I don't want to decide about it yet, but > > since it shares most of its features I choose this name for now. > > > > The Plugin Interface > > > > * Settings: > > - make use of libemeraldengien settings backend > > => could cause problems because Metacity and KDE have different backends > > - maybe extent it so it would better fit our needs > > - but keep in mind that we won't need a second implementation of the > > compiz options system > > > > * Event handling: > > - provide notifies for plugins for some specific events > > - not sure which one will be needed > > - however resize/move/enter/leave will probably be included > > > > * Integration into Emerald-2: > > - standard button drawing will be probably handled by plugins > > - window title drawing probably too > > - we need a system so plugins can sign up for providing functions > > => wrapping stack like in compiz > > => slot system, so only one plugin at the same time can sign up for it > > > > * Integration into DE's: > > - add a plugin for Metacity support > > - maybe port the KDE decoration also to a plugin (if thats possible) > > > > Regards, > > Patrick > > You're welcome to improve emerald, rewrite it or write a completely new decorator, I'm definitely not going to stand in the way of that. However, I suggest that you avoid duplicating work when not necessary and avoid creating alternatives to existing solutions. libdecoration contains code that is used by all decorators. If you find some code that makes sense for more than one decorator, it likely makes sense to put that code in libdecoration. What's missing in current decorators? The following is what I think is missing and how it's most properly fixed. KDE - Expose a few things in kwd that will make is possible for kwin plugins to use alpha channels and less resources. That's it, the kwin plugin API is flexible enough do do pretty much anything so I don't see a need to create an alternative here. GNOME - Th
Re: [compiz] [PATCH]Make wobbly's bezier patch to work with grids that aren't 4x4.
On 5/2/07, David Reveman <[EMAIL PROTECTED]> wrote: On Wed, 2007-05-02 at 01:02 +0300, Roi Cohen wrote: > This patch is not supposed to make bezierPatchEvaluate any slower than > it is right now for 4x4 grids. > 4x4 grid is hard-coded anyway (but inside a define), and this patch > will just make it possible to people who want to hack this plugin to > make bigger grids (of course, bigger grids will affect performance). > So this patch actually doesn't change anything, but the "correctness" > of this function, and also shouldn't have any performance affect. You're adding branching, two loops, calls to 'pow' function and a bunch of divisions to a function that is often executed many thousand times per second. It's not obvious to me that this wont have a performance impact. I understand that it's a correction fix but removing those GRID defines and making it obvious that the code is hard-coded to 4x4 and not allowing it to be changed is just as correct. As your testing proved that changing it to anything but 4x4 doesn't make much sense, I find this more appropriate as we don't have to worry about the possible performance impact those changes might have to bezierPatchEvaluate. And it's less correct not more correct. A bezier curve has 4 control points, a bezier patch has 4x4 control points. If you want to hack something up to allow more control points, fine, but it's no longer a *bezier* patch. And the main reason for using the bezier patch instead of just using enough model object and controlling the grid using their positions was to *cut down* on the number of control points to reduce the ripple propagation time through the grid. Just because something can be made configurable doesn't mean it's a good idea. Kristian ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Wobbly jerkyness
On Sun, 2007-04-29 at 17:54 +0800, Sam Spilsbury wrote: > About a month ago, David made a commit to wobbly to the spring engine > which has introduced some bugs. They are hard to explain so bear with > me. > > In a sense, the wobbly plugin does not seem as smooth as it used to be > and the windows jerk all over the place. For example, I sometimes > notice that when I move a large window (around 2/3 of the size of the > desktop window), If I moved it down, the top of the window would jerk > up then come down quickly. If you want me to explain further then let > me know I didn't change anything in the wobbly plugin, I changed how the move plugin works. The jerkyness and high CPU load is actually expected behavior. The high CPU load is caused by the move plugin changing the server-side window attributes to reflect the current position of the window in real-time. The move plugin doesn't have to do this but it's important that things don't break when it does. I've already been able to fix a number of performance issues after making this change and I think there's some more low hanging fruit that can be taken care of quickly. Eventually, I'll make it possible to not have the move plugin update the window attributes in real-time and I can guarantee that performance will be at least as good as before I did these changes to the move plugin. However, before I can make this possible we need to improve the way window animations are performed. What the move plugin was doing before was wrong and I'm not going to change back to that. You're very welcome to help out with testing, profiling and fixing issues related to how the move plugin currently works. If you're not interested in that and if you can't live with the issues and performance of the current move plugin, you're welcome to use an older version of the move plugin with the bad but better performing behavior. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] White boarders on size 32 shadows. Intel platform only
On Sun, 2007-04-29 at 17:43 +0800, Sam Spilsbury wrote: > Recently, I brought up a topic about white boarders being drawn > instead of shadows in Gnome-Window-Decorator. A patch was made up by > gandalfn to correct this by making 32 pixel shadows 33 pixels, however > the patch was not committed because it was a workaround. > > This is a huge functional annoyance to us intel users and needs to be > cured. There are two soultions I can think of: > > 1 Get in contact with the X.org i810 team and ask them to correct the > issue in their driver which does not allow 32 pixel shadows to be > drawn. > 2 Allow the user to specify in GConf or something the depth of the > shadows that GWD creates. Emerald from Beryl currently allows this so > I don't understand why it would be too hard to implement. > > Yes I *know* #2 is more like a workaround but at least it allows the > user to specify how big they want this shadows to be. (Please dont > confuse this with X-offset adn Y-Offset). I did some quick testing and the problem indeed seem to be a driver issue but I haven't had time to track down exactly what's causing it. There's nothing we can do until someone have been able to track it down. You can enter a intel 3d driver bug for this if you want and if we're lucky someone might be able to help us track this down. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Wobbly jerkyness
> On 5/2/07, Sam Spilsbury <[EMAIL PROTECTED]> wrote: > > Weird, I dont even know your e-mail adress Oh > well, forwarded. > > Anyways for those of you on the compiz list, here is > the inital problem. > > Wobbly is jerky and it seems that the move plugin is > the culprit with high CPU usage No progress on this? Am I and Sam the only ones affected in this list? Joel ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Strange behaviour in move plugin
David Reveman wrote: On Thu, 2007-04-05 at 18:55 +0200, Bellegarde Cedric wrote: 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. I know that both gwd and kwd are doing a bunch of unnecessary work each time the position changes and I'll fix that sometime soon. There might always be applications that are doing a lot of unnecessary work each time the window position changes so having support for only updating the server-side position when we're finished moving a window is useful and I'll add that back to the move plugin later in a more appropriate way. The old way it was done was bad. I have been looking at this a bit more (just at reproducing it) and I have noticed some strange effects. I do not think its a problem with the move plugin or the toolkits, it seems related to the decorators. If I reload compiz from a terminal and then shake that terminal the movement is fluid and smooth. I notice that the kwd buttons go missing as well. When I click to another window the decorator buttons reappear and movement only updates when I pause the mouse movement (ie. I see the horrible jerkyness). I have seen the decorator lose buttons before so it looks like this problem is actually a combination of a couple of changes, but possibly related to that. Does this sound reasonable? Sorry, I forgot to copy the list on this one, I notice that killing kwd fixes the problem, can anyone else see this? - 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] [PATCH]Make wobbly's bezier patch to work with grids that aren't 4x4.
On Wed, 2007-05-02 at 01:02 +0300, Roi Cohen wrote: > This patch is not supposed to make bezierPatchEvaluate any slower than > it is right now for 4x4 grids. > 4x4 grid is hard-coded anyway (but inside a define), and this patch > will just make it possible to people who want to hack this plugin to > make bigger grids (of course, bigger grids will affect performance). > So this patch actually doesn't change anything, but the "correctness" > of this function, and also shouldn't have any performance affect. You're adding branching, two loops, calls to 'pow' function and a bunch of divisions to a function that is often executed many thousand times per second. It's not obvious to me that this wont have a performance impact. I understand that it's a correction fix but removing those GRID defines and making it obvious that the code is hard-coded to 4x4 and not allowing it to be changed is just as correct. As your testing proved that changing it to anything but 4x4 doesn't make much sense, I find this more appropriate as we don't have to worry about the possible performance impact those changes might have to bezierPatchEvaluate. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Wobbly jerkyness
I can confirm this. Move is jumpy, and wobbly is jerky. This makes it impossible to use compiz git right now, at least for me. Joel On 5/2/07, Sam Spilsbury <[EMAIL PROTECTED]> wrote: Weird, I dont even know your e-mail adress Oh well, forwarded. Anyways for those of you on the compiz list, here is the inital problem. Wobbly is jerky and it seems that the move plugin is the culprit with high CPU usage ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
