How menus paint

The following sequence of images attempts to explain why users see flashes while moving the mouse across menus in Eclipse. It explains how X windows that have no background colour or pixmap set are drawn.

Also see bug 63516 and GNOME bug 113310 which describes a solution which has gone into GTK+ CVS.

We start with the Source menu open, and we are moving to the right to the Refactor menu. When the menu's window is unmapped, X fills in the background of any Windows underneath that have a background colour or pixmap set.

The Eclipse editor shuts off background drawing. So does the bar to the left of the editor, as well as the down arrow for the view's menu. The following shot shows these windows and how they leave around the contents until they redraw.

When our new menu opens, I believe it gets to redraw before the underlying window runs an evfent loop and has a chance to redraw its contents.

Here is the final shot with all the outstanding paints handled.

Firefox, unlike a normal GTK+ application, shuts off background drawing by X on all of its subwindows. This means that you never have a flat colour painted onto its window by the X server, you only see double drawing of the menus.

We start with the Edit menu and move to the right.

When the Edit menu is unmapped, because none of the Windows below it have a background set, X does not paint any solid colours. When the new window is mapped, the old one is still visible even though its window has been unmapped.

Here is the final shot with all paints completed.