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?).
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
