Does perfect masonry respect sorting at all?

[KATT]

Hey!

I would like that a small specifications on how the algorithm operates gets added to the readme.

The main question is: Does perfectMasonry respect sorting?

In the top of the source code there's the following statement:

Does similar things as the Isotopes "masonry" layoutmode, except that this one will actually go back and plug the holes

Is this statement true? I.e. does it not disregard sorting and rather, does a "normal" masonry layout then recursively goes around the layout and tries to fill the holes?

If we have a grid like this generated by normal masonry (numbers symbolises priority by sort, and X empty space):

[1 BRICK] [2 BRICK] [3 BRICK] [ EMPTY ]
[   4 BIG BRICK   ] [5 BRICK] [6 BRICK]
[7 BRICK] [   8 BIG BRICK   ] [9 BRICK]

Would perfectMasonry iterate through this, move [5 BRICK] to [ EMPTY ], then simply push everything else one step and create this? Or would it not care if it was 5/6/7 that was moved?

[1 BRICK] [2 BRICK] [3 BRICK] [5 BRICK]
[   4 BIG BRICK   ] [6 BRICK] [7 BRICK]
[   8 BIG BRICK   ] [9 BRICK] [ EMPTY ]

[mikkotikkanen]

Unfortunately no. The way it works at the moment is that it keeps track of any holes that might be left into the "masonry wall" and plugs them with elements that might fit into them. So, no, it doesn't respect sorting. Having sorting that would work everywhere in this kind of application would be next to impossible anyways, so didn't bother with it. :)

[KATT]

That's almost the there, if it just find these fitting bricks in the order that they are according to the sorting and did that recursively it would have this effect.

The principle just needs to be to find the first fitting brick to an empty slot.

Example

The logic I need is pretty straight forward.

1. Do normal sorted masonry
2. Find empty non-locked slot in grid
3. Find closest brick afterwards that fits in this space.
   • If not found, mark as locked
   • If found move brick to empty space
4. Go to 2.

Do recursion above while there are no empty non-locked spaces or in the main grid.

How it would iterate over the masonry.

Start state

[1 BRICK] [2 BRICK] [3 BRICK] { EMPTY }
[   4 BIG BRICK   ] [5 BRICK] [6 BRICK]
[   7 BIG BRICK   ] [8 BRICK] [9 BRICK]

Step 1

[1 BRICK] [2 BRICK] [3 BRICK] [5 BRICK]
[   4 BIG BRICK   ] { EMPTY } [6 BRICK]
[   7 BIG BRICK   ] [8 BRICK] [9 BRICK]

Step 2

[1 BRICK] [2 BRICK] [3 BRICK] [5 BRICK]
[   4 BIG BRICK   ] [6 BRICK] { EMPTY }
[   7 BIG BRICK   ] [8 BRICK] [9 BRICK]

Step 3

[1 BRICK] [2 BRICK] [3 BRICK] [5 BRICK]
[   4 BIG BRICK   ] [6 BRICK] [8 BRICK]
[   7 BIG BRICK   ] { EMPTY } [9 BRICK]

Step 4

[1 BRICK] [2 BRICK] [3 BRICK] [5 BRICK]
[   4 BIG BRICK   ] [6 BRICK] [8 BRICK]
[   7 BIG BRICK   ] [9 BRICK] { EMPTY }

I should probably have a go of creating my own variant of a perfect masonry to have this effect, or do you think this would be able to go in the plugin as a mode?

[mikkotikkanen]

Yes but any kind of sorting only works when container is wide enough compared to the tiles. When the container shrinks, there is no way to build a masonry that is sorted

[KATT]

That is true; and that's why my grid is responsive but with fixed breakpoints rather than being fluid. But you could also approach that problem by changing the columnWidth on resize and have percentage-based item tiles.

[KATT]

Or by centering the masonry.