On Tuesday, April 16, 2019 10:04 PM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Tue, Apr 16, 2019 at 08:13:12PM +0200, Maarten Lankhorst wrote: > > > Op 16-04-2019 om 15:42 schreef Ville Syrjälä: > > > > > On Tue, Apr 16, 2019 at 03:28:15PM +0200, Maarten Lankhorst wrote: > > > > > > > Op 16-04-2019 om 15:20 schreef Ville Syrjälä: > > > > > > > > > On Sat, Apr 13, 2019 at 11:13:27AM +0000, Simon Ser wrote: > > > > > > > > > > > From: Ville Syrjälä ville.syrjala@xxxxxxxxxxxxxxx > > > > > > This adds basic immutable support for the zpos property. The zpos increases > > > > > > from bottom to top: primary, sprites, cursor. > > > > > > I was thinking a bit about how we might go about testing this. > > > > > > > > > > We probably want a basic test that just checks that if any > > > > > plane has a zpos prop then all planes should have it. > > > > > This would be a good test for BAT. > > > > > A functional test would stack the planes up in some way and > > > > > compare against a software rendered reference. IIRC there was > > > > > a zpos test case floating around but that depended on alpha > > > > > blending which we don't necessarily have. > > > > > But with semi-overlapping planes you would accomplish the same, without alpha dependency. > > > > > > > > Something like this? > > > > [BG] [Sprite 1] [Cursor] > > > > [Primary] [Sprite 2] > > > > Should probably be good enough. Though I was pondering is there a > > > > way to position an arbitraty number of planes such that the > > > > resulting picture has a visible region for every possible > > > > combination of planes? > > > > n planes, width = width / (n + 1) > > position = n * 3/4 * plane_width ? or something > > If each plane has its own color, then it would work.. > > That's not going to hit all the combinations. > > Three is easy, you just position the planes in a triangular sort > of shape. But four already seems hard. Or maybe I'm just not smart > enough. Probably needs some graph theory math proof or something. > > I suppose you could do thatr staircase type approach you suggested, > and them swap the planes around a bit. I think that should cover > everything eventually. But I was hoping for a cool way to check > everything from a single frame :) That's an interesting problem. Goal: an image which contains, for each pair of planes (P1, P2), a region with these two planes overlapping (and only these two planes). In terms of graphs, if a plane is a node and a two-plane overlap is an edge, it means we want a complete graph (each node has an edge to all other nodes). If we only have square planes, it's already impossible to get a solution for 4 planes (the graph contains an edge that crosses another edge [1]). However if we get non-square planes (ie. we have an alpha channel) it becomes possible. If n is the number of planes, I can imagine to draw (n - 1) little squares on each plane (the rest being totally transparent), each of them intersecting with one of the others planes' squares. This would mean we'd have n * (n - 1) little squares total, and n * (n - 1) / 2 couple of squares that intersect (this matches the number of edges of a complete graph). Thoughts? Is this clear enough? Is it acceptable to require an alpha channel? Am I mistaken? [1]: https://en.wikipedia.org/wiki/File:3-simplex_graph.svg _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
