Skew bug with egl
spitzak at gmail.com
Tue Aug 14 15:27:18 PDT 2012
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?).
More information about the wayland-devel