Hello
To integrate a compositing manager well with the rest of the desktop,
new hints and protocols between applications and compositing managers
are needed. This message is intended to start that discussion.
*** Window types
A compositing manager deals with all windows that are visible on the
screen, even override-redirect ones. This means new window types
are needed so the compositing manager will know how to decorate the
override-redirect windows with translucency and shadows etc.
Here are some typical override redirect windows:
- DND windows (showing drag icons etc.)
- Tooltips
- Menus, drop-down menus and right click menus.
- Combo box popups
- Notifications ("you are are running out of battery" etc.)
- Random little popups, such as the search boxes on trees and lists
Also many applications pop up their own app-specific override-redirect
windows for whatever reason.
One possibility is to add a bunch of new possible window types to the
_NET_WM_WINDOW_TYPE property:
_NET_WM_WINDOW_TYPE_DND_WINDOW
_NET_WM_WINDOW_TYPE_TOOLTIP
_NET_WM_WINDOW_TYPE_NOTIFICATION
_NET_WM_WINDOW_TYPE_DROP_DOWN_MENU
_NET_WM_WINDOW_TYPE_POPUP_MENU
_NET_WM_WINDOW_TYPE_COMBO
That will take care of most of the override redirect windows on a
typical. CM's will still need to deal with unannotated
override-redirect windows from old applications.
Do we need any other types?
*** Letting applications know that a compositing manager is running
Applications need to know if a compositing manager is running, to make
an informed decision whether to use ARGB windows or not. I propose a
new manager selection (as defined in ICCCM section 2.8)
_NET_WM_CM_Sn
where n is the screen number. If someone else claims the selection,
the compositing manager should stop compositing that screen.
*** Synchronizing repaints
The problem is that application windows will often be in an
intermediate state that shouldn't be shown to the user if we can avoid
it.
- A newly mapped window will be completely blank until the application
gets around to drawing something on it.
- The application resizes a child window causing an intermediate state
until the window is repainted. Note: *child window*, not toplevel.
- The application simply doesn't double buffer its drawing (Qt3
basically)
One thing to keep in mind is that multiple windows may need to be
synchronized with eachother. For example, if you open a dropdown menu,
you don't want the menubar to look selected if the menu window isn't
drawn yet or (worse) vice versa. Or an application keeps two windows
in sync; you don't want one to get ahead of the other.
A straightforward approach is to maintain two states for each window:
APP_DRAWS and CM_DRAWS. Then
- when a window is mapped, it is in state APP_DRAWS
- every time the application finishes drawing it sets
the state to CM_DRAWS.
- the compositing manager maintains pixmaps of all windows. Whenever a
window changes state to CM_DRAWS, it updates that pixmap and changes
the state back to APP_DRAWS.
If an application makes sure that it never set CM_DRAWS on a window
until all windows that must be kept in sync with it are ready, I think
this scheme will solve the tearing problem.
The big drawback is that it requires yet another copy of all the
window contents. A way to avoid that would be for the compositing
manager to never paint another frame until all windows were in the
CM_DRAWS state, but I suspect the performance penalty would be too
big.
Comments appreciated.
Soren
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
