Skew bug with egl

[Bill Spitzak]

Oops. I described the shift backwards, it is actually -width mod 16.

If the surface is N*16 wide it is correct.

If the surface is N*16-1 wide then it is skewed with each scanline 1 
pixel to the right of the one above it. The writing code thinks the 
stride is N*16, while the reading code thinks it is N*16-1.

Bill Spitzak wrote:
> Further information:
> 
> Experimenting with resizing clickdot, it looks like it always skews such 
> that line N is shifted width%16 pixels to the right of line N-1, where 0 
> is the top of the window. I also see a width%16 line of garbage between 
> the skewed left/right edges of the surface.
> 
> This implies that the *writing* code thinks the stride is a multiple of 
> 16, but the *reading* code thinks the stride is arbitrary. This is 
> opposite of what I expected, but it seems the bug is in a disagreement 
> between the compositor and clients over what stride to use. The clients 
> seem to be using a stride that is a multiple of 16, but the compositor 
> is using stride equal to the surface size.
> 
> The windows themselves are rectangular, so it looks like the bug is 
> before the compositor combines them together. The resulting composite is 
> drawn correctly to the window (though the x11-compositor width is 1024 
> which may hide the problem here?).
>