Bug 1226723

Marc, which hack are you referring to?

0001-worst-hack-of-all-time-to-qxl-driver.patch
#define HACK_THE_PLANET 1

Original issue (the reason for the patch) is https://bugzilla.redhat.com/show_bug.cgi?id=1020393. Looking at the video seems related to some bug in stream implementation. The patch mainly try to avoid spice-server to detect the streaming (look at the video). I think removing this patch at this stage could cause regressions.
Better things would be to remove the stream bug that cause that strange effects.

(In reply to Frediano Ziglio from comment #5)
> Original issue (the reason for the patch) is
> https://bugzilla.redhat.com/show_bug.cgi?id=1020393. Looking at the video
> seems related to some bug in stream implementation. The patch mainly try to
> avoid spice-server to detect the streaming (look at the video). I think
> removing this patch at this stage could cause regressions.
> Better things would be to remove the stream bug that cause that strange
> effects.

Last time I checked, it caused more harm than good on rhel6 guest, basically breaking any chance of video detection :) 

The best way I could think of to solve this for rhel7 guest is to use the mesa shm patch I proposed:
http://lists.freedesktop.org/archives/mesa-dev/2015-June/086459.html.

The other less efficient and unlikely to happen, is to have x11 bigreq support for PutImage.

I really don't understand all the background of this problem.
Looking at the video at https://bugzilla.redhat.com/show_bug.cgi?id=1020393 is not just performance is that streaming is not working correctly and the patch is a workaround to disable streaming detection.
Or perhaps I don't understand the relationship between the glitches and the performances.

(In reply to Frediano Ziglio from comment #7)
> I really don't understand all the background of this problem.
> Looking at the video at https://bugzilla.redhat.com/show_bug.cgi?id=1020393
> is not just performance is that streaming is not working correctly and the
> patch is a workaround to disable streaming detection.
> Or perhaps I don't understand the relationship between the glitches and the
> performances.

You have to remember that rhel6 and rhel7 are quite different at rendering. in gnome3, mutter/clutter is responsible for compositing and so llvmpipe for sending drawing commands to the driver, mostly large images.

Video detection is not in sync with the rest of drawing, so you get glitches if done wrong. Dave hack is breaking video detection altogether, to avoid the glitches. But this of course lower performance (more weird drawings) and prevent video streams

Today, clutter is better at updating only the modified regions, and spice server video detection also got improved.

Even if removing Dave hack, the update regions are still quite big (a whole app window for ex), so a large update is done with many PutImage of various size, confusing video detection, typically with various video strips as seen in bug 1020393. Instead the region update should be done in a single request. Then video detection works properly. Having BIGREQ implementation for PutImage is one way. The better way is to use XShm to also avoid extra copy, and this is what I've done http://lists.freedesktop.org/archives/mesa-dev/2015-June/086459.html.

iirc, in short:
1. the hack is terrible breaking many chances of correct video streaming even with rhel6, and should no longer be so bad with rhel7 due to clutter and server improvements
2. video glitches are still possible due to PutImage being splitted in various updates, but the xshm mesa patches allow for a single update of regions & save memcpy (which is really nice for video or animations)

removing 1 & adding 2 is what should be done

Created attachment 1084662 [details]
Package patch

For developers are mostly done (see previous patch)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0761.html