Bug 7671

Created attachment 6375 [details] [review]
Patch to fix a case where a pinned source pixmap forces no acceleration

This patch fixes the case where a single src or mask pixmap, which is pinned in
system memory stops acceleration. It relies on uploadToScratch, if present, to
upload the pixmap to a scratch area and the compositing operation will be
accelerated. This seems to be a quite common case. 

In the current form it's only implemented for "greedy", but it could probably
be moved up to be valid for all heuristics.

Created attachment 6376 [details] [review]
Always accelerate movement of transparent and shadowed windows.

This patch requires that the driver can always accelerate one-pixel repeat
source and mask pixmaps regardless of their location. It might be only the via
driver that does this ATM?

Anyway, If all drivers can detect that the address of the pixmap is not in FB
memory and fail prepareComposite it should be safe to commit. (All drivers
implementing uploadToScratch need to be able to do this today anyway, since if
uploadToScratch fails, prepareComposite will be called with a system pixmap
address). 

This patch fixes the case where the destination is in FB and both the source
and mask is in system memory. Either because of a bad greedy score (Netscape,
skype), or because one of them is pinned. AND one of the pixmaps is a one-pixel
repeat pixmap.

This case might seem awkward, but it's a typical case with the "greedy"
heuristic and an application that does a lot of software compositing and then
displays the result in a transparent window. 

With this patch, movement of transparent and shaded windows with the "greedy"
heuristic should always be accelerated, provided the driver implements
uploadtoscratch and the scratch area is large enough to hold the pixmap.

Created attachment 6378 [details] [review]
Always accelerate movement of transparent and shadowed windows.

Fixes segfault in patch 6376

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Tagging patches; will triage later.

EXA isn't using the UploadToScratch driver hook any more, and it is scheduled to be removed next time the ABI needs to be bumped. It was basically a bandaid for bad migration, better to just fix that.