Applications using non-double-buffered drawing using cairo (e.g. Abiword)
can draw directly to the window using cairo and thus manage to avoid
the automatic flushing of outstanding moves. This can cause redraw
inconsistencies like bug 593507.
We fix this by always flushing when exposing non-double-buffered widgets.
If we move, resize or otherwise change a window from inside a (double
buffered) expose handler we can run into issues with double buffered
paints that have already been ended but have not yet been commited
to the window from the implicit paint pixmap.
For instance, any copies of source regions due to a window scroll need
to take these into account, and any operation that causes some drawing at
a destination covered by the implicit paint region would be overdrawn
when the implicit paint is ended.
So, before we do any window-hierarchy changing operation while an implicit
paint is in effect we flush all moves and already commited paints.
When a window is moved or resized from a double-buffered expose handler
we can't really just copy the window region around, as the window
will be overdrawn with the double buffered region when the expose returns.
Instead we remove all regions with outstanding implicit paints from the
region to be copied and just mark this area as invalid to be redrawn
later.
This fixes bug 594880.
Its not correct for recurse gdk_window_process_updates_internal, as
the outer instance will overdraw the inner. So, protect against
gdk_window_process_updates() being called while in an expose
handler.
This shouldn't be a repaint problem, as eventually the idle handler
will cause the updates to be processed.
Some recent versions of libtoolize output a version blurb like:
libtoolize (GNU libtool 1.3110 2009-07-01) 2.2.7a
Don't get confused by the numbers inside the parens.
We used to handle zero height/width specially in the non-double buffered
case due to the weird behaviour of XClearArea in this case. However
this is undocumented, incompatible with what happens on double-buffered
drawing, and just not a good API. So, we drop this behaviour, having
fixed gtkclist.c which used this.
There are two issues here. First of all an ignored update didn't
use to unset update_idle which could cause all further idle repaints
to be ignored. (Bug #591583)
Secondly, if we ignore the process_all_updates we may end up not updating
the windows in update_windows unless something else triggers an update.
So, we handle this by checking for recursions and scheduling a new update
at the end of the outermost process_all_updates.
Fixed the button-sensivity patch done to GtkComboBox to account for
changes in appearance (changes to the appears-as-list style property).
Also, in list-mode, the event box that has been created below the cell
view also needs to have its sensitivity updated.
Commit 3f306a4042 made it possible for
gtk_tree_view_top_row_to_dy() to be called recursively. (In a different
way than was already guarded for). This caused a single test case in
the scrolling test suite to fail. We now also guard for recursive calls at
the beginning of gtk_tree_view_top_row_to_dy().
