Thanks to Iain Holmes and Thomas Thurman for improvements in this version. This is the first unstable release to contain the new compositor; please try it out and let us know how it goes for you. Downstream maintainers should note that its GConf key is initially turned off in src/metacity.schemas.in and consider whether to turn it on by default in their packages.
- merge compositor branch! (Iain) (GNOME bug 499081)
- print “Subversion” and not “CVS” when building (Thomas)
Jorge González (es), Kjartan Maraas (nb), Daniel Nylander (sv)
- 3d3ac7dc8e52981af032e35171789e60 metacity-2.21.5.tar.bz2
- eef55d7ce921b23d0749155876d53873 metacity-2.21.5.tar.gz
Photo: Footbridge over the River Ver, Hertfordshire, England. Photographer: Gary Houston. Public domain.
32 thoughts on “2.21.5 is out, with the compositor”
Correct me if I am wrong but one of the points of compositing is to keep a copy of the window so you do not have to force the application to redraw each time two windows overlap. Now with 2.21.5 if I switch desktops it still takes a noticable while to redraw all the windows (especially if Firefox is there). Shouldn’t be enough to pull pixmaps from offscreen compositing buffers?
Whenever the desktop is switched the unmapped windows are remapped, therefore they need to be redrawn as any drawing operation that occurred while the window was unmapped didn’t actually do anything, so no, it isn’t enough to pull pixmaps from offscreen compositing buffers (plus the offscreen compositing buffers are (usually) destroyed when a window is unmapped)
Do other WMs implement workspaces other than by unmapping windows? Should we in future, perhaps?
Compiz does not unmap windows when they go to another desktop as it creates one large desktop and scroll over it rather than managing multiple separate desktops. As the desktop is seamless there you can have a window with one half visible on desktop 1 and the other on desktop 2. Makes sense in the “desk” metaphor.
On my i945GM, the compositor is noticeably slower than the normal rendering mode.
thomas: its the age old workspace vs viewport argument again. Metacity does workspaces, compiz does viewports
And compiz does appear to unmap when the window isn’t on the workspace
if (desktop == 0xffffffff || desktop == w->screen->currentDesktop)
hideWindow then calls XUnmapWindow on the window.
If the windows are unmaped when leaving screen then it seems compiz keeps track of their composition buffers as it’s possible to see thumbnails of windows from different desktops. Could this be done for metacity? It would be useful if someone decided to implement an expose clone for example.
Something urelated, is this known behaviour or should I file a bug? Sometimes a thumbnails is missing when alt+tabbing:
Metacity does do it, but once the window is unmapped the updates stop.
(see http://ktown.kde.org/~fredrik/composite_howto.html for details)
Its known behaviour, its because metacity wasn’t able to cache the thumbnail because it didn’t exist. I’m assuming that terminal was minimised when you turned on compositing?
Compositing was on for the whole desktop session. I even minimised and restored the window but the thumbnail appeared on its own minutes later.
Nice work. However I have Scott Robinson’s problem, on my r300 card (with EXA) rendering is slower than with compositing disabled and even slower than with metacity+xcompmgr. It’s like double rendering wasn’t enabled…
Then you need to expose some options, at least through gconf (enable/disable shadow, shadow size, transparent unfocused windows) and to add a new keybinding to change the alpha value of windows, to make them transparent if the user needs to see what’s under…
Congratulations for this importan improvement and thank you for your work!
I agree that a gconf option to control shadows would be nice but I strongly disagree with adding keybindings for or automatically modifying alpha. It’s up to the application to control the alpha and metacity is supposed to be a usable WM.
One thing I found useful in compiz is the ability to mark unresponsive apps as such but in general apps are supposed to be responsive so I’m not sure it fits into GNOME.
I can confirm that it’s pretty common for new windows to get mapped without metacity compositor noticing. They get proper thumbnails when remapped (switching desktops forth and back is enough). I think it might deserve an entry in bugzilla.
Patrys: if you’re losing windows, it definitely should go in bugzilla. Is it reproducable?
Not literally losing windows, just thumbnails, see bug:
I have been using the compositor-enabled metacity for about a week now. Before that I was using compiz, but I rather like metacity.
One thing I really like are the window previews in the alt-tab dialog. However, I find the previews a tad too small so I have increased the size a bit in my version.
My question is then: is there a possibility to have the preview sizes adjustable via some gconf setting? (if this is not the right place to ask, let me know and I will repost the question whereever you want me to)
Anyways, thanks for such a nice and simple window manager.
Congratulations, saviours of the world!
I agree that the viewport approach make the window-manager seeming _a_lot_ faster.
And for other ideas, I suggest you to read this:
Great work. It seems pretty stable to me but a bit slow.
I like this window switcher of compiz:
it looks cool and the “thumbnails” are big enough to be usefull ;)
btw, if i’m scaling totem while playing the video flickers a lot but doesnt if i switch compositing off.
Thanks for the work!
This is all very pretty, I like it. Thank you :)
I upgraded to 2.21.5 today to try out the compositor, and was generally impressed – but I noticed that unlike xcompmgr, it doesn’t seem to trigger RGBA mode in gnome-terminal, so I only get faux-transparent terminals instead of real-transparent ones. I believe this was the magic commit that made xcompmgr work, as documented in the NetWM spec.
It definitely works, but you have to restart gnome-terminal after turning on the metacity compositor. That’s a bug in gnome-terminal rather than metacity. :-)
Oh, hey, you’re right – I was confused because when I logged in, Metacity was running (obviously) before I started gnome-terminal, and the transparency didn’t work. After toggling the compositor and restarting gnome-terminal, now it works fine.
I’m probably completely missing the point, but:
Enabling compositing on my machiene (Ubuntu 7.10, nvidia 6100 onboard/nonfree driver) seriously bogs down switching between workspaces (which is really annoying, as I make heavy use of virtual desktops).
Switching to a workspace, containing a maximized opera window, I see the window go black for a moment and then redraw. This is worse than the non compositing behaviour, as the blanking is very irritating and takes more time (actually I was searching for a way to get metacity switch between desktops as smoothly as compiz does).
Patrick: See Patrys’s comment in comment 1 and the answers given there. I think we definitely all need to have a talk about this and I think I’ll be raising a bug.