[PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v2)

[Adam Jackson]

On Thu, 2015-04-23 at 13:24 -0700, Jasper St. Pierre wrote:
> If a window has ForgetGravity in its bitGravity, that very likely
> means it will repaint on the ConfigureNotify / Expose event, and thus
> we don't have to copy the old pixmap into the new pixmap, we can 
> simply leave it blank.
> 
> Preventing this copy is super simple to do and a big win on small
> devices where these blits can be expensive.
> 
> A better approach would be to actually obey BitGravity correctly 
> rather than assume NorthWestGravity always, but this is a big 
> speedup for the common case.

I would prefer to see the "can we optimize this" check done in
compReallocPixmap, the way my initial patch did. That way we can
destroy the old pixmap before allocating the new one, which is a nice
reduction in memory pressure (in both address space and dirty
cacheline senses).

I think we also want to treat the combination of {auto redirection,
forget gravity, null background} as needs-copy. xcompmgr -a should
look as much like uncomposited X as possible. If we skipped the copy
in this case, we would also skip the background paint, but the window
would still be "dirty" from composite's perspective, so the next
screen update will paint whatever garbage is in the uninitialized new
pixmap. That wouldn't match classic X's "the existing screen contents
are not altered" semantics.

I don't think the flicker thing Aaron mentioned is an issue.  The copy
is a waste for Forget windows in any case, because it's immediately
followed by a window-sized background paint (assuming defined
background).  So auto is already flickery, and manual already has the
sync protocol.

- ajax