Re: [compiz] gtk-window-decorator shadow crash
David Reveman wrote: On Tue, 2006-12-12 at 03:58 +, Mike Dransfield wrote: If you set shadow_offset_x and y to 0 then gwd crashes with this message. The program 'gtk-window-decorator' received an X Window System error. This probably reflects a bug in the program. The error was 'RenderBadPicture (invalid Picture parameter)'. (Details: serial 16033 error_code 176 request_code 154 minor_code 8) hm, it doesn't for me. what other shadow parameters do you use? Sorry, I think you would need to choose shadow radius of 0 as well. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] dbusSendChangeSignalForOption crash
I seem to be having problems with the latest dbus code. Here is a backtrace. This is happening at startup. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47449612229888 (LWP 28353)] 0x2b27b87991c0 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x2b27b87991c0 in strlen () from /lib/libc.so.6 #1 0x2c1b0657 in dbus_watch_handle () from /usr/lib/libdbus-1.so.3 #2 0x2c197cc1 in dbus_set_error () from /usr/lib/libdbus-1.so.3 #3 0x2c19d6f1 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3 #4 0x2c19ded9 in dbus_message_append_args_valist () from /usr/lib/libdbus-1.so.3 #5 0x2c19e265 in dbus_message_append_args () from /usr/lib/libdbus-1.so.3 #6 0x2c9fb565 in dbusAppendOptionValue (d=0x8, message=0x6714d0, type=7368532, value=0x6702f0) at dbus.c:673 #7 0x2c9fc0b3 in dbusSendChangeSignalForOption (d=0x52a260, type=CompOptionTypeAction, value=0x6702f0, path=0x706f54 Address 0x706f54 out of bounds) at dbus.c:975 #8 0x2c9fc137 in dbusSendChangeSignalForDisplayOption (d=0x52a260, o=0x6702d0, plugin=0x2c1ca8c7 dbus-marshal-basic.c) at dbus.c:994 #9 0x2c9fc37a in dbusSetDisplayOptionForPlugin (d=0x52a260, plugin=0x6704f0 switcher, name=0x675801 next, value=0x4) at dbus.c:1066 #10 0x2ad15f52 in gconfGetOptionValue (d=0x52a260, key=0x8 Address 0x8 out of bounds) at gconf.c:637 #11 0x2ad1618c in gconfInitOption (d=0x52a260, o=0x2c1ca8ed, screen=0x2c1ca8c7 dbus-marshal-basic.c, plugin=0x706f54 Address 0x706f54 out of bounds) at gconf.c:777 #12 0x2ad16665 in gconfInitPluginForDisplay (p=0x671620, d=0x52a260) at gconf.c:930 #13 0x004221de in pushPlugin (p=0x671620) at plugin.c:239 #14 0x0040a432 in eventLoop () at display.c:1405 #15 0x004089a8 in main (argc=4, argv=0x737638d8) at main.c:242 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] reason for bad performance on i915 (AIGLX)
On Tue, Dec 12, 2006 at 01:26:43AM +0100, David Reveman wrote: On Thu, 2006-11-30 at 11:20 +0100, gandalfn wrote: Hi, In my ubuntu packages, to compiz work properly on AiGLX and for performance issue i continue to apply two patchs of Kristian Høgsberg : http://people.freedesktop.org/~krh/compiz-on-aiglx/compiz-patches/06-glfinish.patch http://people.freedesktop.org/~krh/compiz-on-aiglx/compiz-patches/02-tfp-server-extension.patch I've found the reason to why the glfinish patch made a difference (typo in makeScreenCurrent). Let me know if compiz head doesn't fix this problem. I applied commit fa8fa641bd820d16cb2b2923d0af2f230ed43ac4 to my local compiz 0.3.4 package (replacing the glfinish patch) and it's working beautifully. Thanks! btw, 06-glfinish.patch is bad because it calls glFinish after drawing a frame, basically blocking compiz from doing any work until the server and gfx hw is done with all rendering. The main loop in compiz calls glFinish before drawing a new frame instead, this way we block only when necessary. Things definitely seem to be noticeably snappier with your fix. tfp-server-extension patch doesn't make sense to me, it must be client side libGL issues. The tfp patch is still needed here. (Debian sid, xorg 7.1, mesa 6.5.1, foss radeon driver 6.6.3) -- CJ van den Berg mailto:[EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] signature.asc Description: Digital signature ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Dbus improvements (was Include option type in gconf schema)
On Dec 11, 06 19:23:09 +, Mike Dransfield wrote: I hope you dont mind, but I would like to maintain a version of dbus and annotate for a while so that I can work on a better API. A git repository would be useful here because it would make it easier for people to test and provide feedback. We are having trouble with exchanging tarballs over a forum :) People typically use a per-user git repository on freedesktop for these things. I haven't used one so far, so I do not completely know how to set it up, but I guess you have to kick someone with administrator rights on anarchy or annarchy (both exist, and I do not remember which one was for what ;) CU Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Patch to wobbly snap for outputs
On Mon, 2006-12-11 at 22:48 -0700, Mike Cook wrote: On Fri, 2006-12-11 at 21:32 -0700, David Reveman wrote: After looking at this I found the correct solution to be to just snap to window struts instead of any workarea. I've pushed out changes that should take care of this. I don't have access to a multi-head setup right now so I can't verify that it works OK. Please give it a try. Hm, somebody will have to donate a couple extra monitors... ;) After a quick first test on a single head machine I think there's a typo, as it seems to be ignoring the struts and just snapping to screen edges for me. Also, I'm not sure if the struts are the best option-- more on that below... :) Don't worry, I have a multi-head setup at my office. I'm just not there right now. You're right, a typo caused it to not work at all. It should be fixed now. While looking at this I also found an issue that caused snapping to normal windows to be a bit incorrect, it should be correct now. I've included a few more window types in snapping. However, including dock windows is probably not a good idea. Sometime windows with dock type and below state are used for windows that shouldn't have any decorations and stick to the desktop. We don't want to snap to those. Ah, yeah, I wasn't sure if dock type might be used like that. I personally think we should include these inner struts when calculating the workarea for each output (which also helps window maximizing), and only ignore them in the screen workarea case (for the _NET_WORKAREA hint). What do you mean by inner struts? Each workarea rectangle should be the maximum rectangle that doesn't intersect any struts. If that's currently not the case, it should be fixed. Sorry, by inner struts I was trying to refer to those on the inside edge between two outputs. Say I have 2 monitors, and I have a vertical dock covering the right edge of the left monitor, or the left edge of the right monitor-- basically down the middle of the screen. Those type seem to be currently ignored. OK, lets find out why they are ignored then. What struts are those vertical dock windows using? If those windows are not just setting any strut hints, then it's not much we can do. If the workarea isn't good enough for a plugin it should instead look at the strut hints for each window like the wobbly plugin is now doing. We can add a region to the output struct that is the output area minus all window struts if that turns out useful for plugins. I can't think of any time the output's workarea wouldn't work, as however that is calculated we should probably use it to be consistent. Here are the issues I ran into as I was trying to work on this: 1- Struts that are on those inner edges like I described before are currently ignored in the output workarea calculation. So, for instance, a window will maximize to the output edge under that dock. This shouldn't happen. I'll make sure it gets fixed once I know why it currently doesn't work. 2- A dock may cover the top or bottom of only one output. That strut should not be considered when snapping or maximizing on a different output. Why this behavior? 3- In the case of the total screen's workarea we should ignore those in #1 and clip to those in #2 to have the largest total area (at least until the workarea hint can handle multiple regions, or whatever other solution the spec comes up with). The screen workarea could be the current outputs workarea and be updated as the current output changes. This might confuse desktop windows, though. 4- Also, say you have two or three panels across the top of an output. You wouldn't want to snap to each one separately, but just to the lowest one, which should be what the output workarea calculation would give you. I would want to snap to each one separately and have windows placed smarter then just in the workarea rectangle. Windows should still be maximized to the workarea rectangle, of course. 5- And finally, in the patch I was intending that a window also snaps to the edges of each output, which is the current behavior that I get with metacity, I believe. I agree, snapping to output edges makes sense. I can easily make the current wobbly code do that. So, in the end, that's why I was thinking that each output workarea would be the best region to snap to, if they include calculations for all the struts at any edge within that output. That then also covers snapping to the output edges (strut or not). Sorry for the long response... ;) There's clearly some more work to be done here and I appreciate your help with getting this right. Thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
