Javascript library to help creating high quality justified galleries of images. Used by thousands of websites as well as the photography community 500px.
PR #286 attempted to fix a doubled margin between rows, however in my use case, while it solved that, it increased the images per row, thereby reducing the height of each image. Especially with a number of very wide, but short, images, this led each row to be significantly shorter then before #286.
I believe the source of that problem is that after #286, we'd buffer the next entry, add it's aspect ratio in the buildingRow, then determine if the buildingRow (while accounting for the aspect ratio a second time) was below the rowHeight to flush the row, thereby treating rowHeight like a maximum height.
It seems the intention prior to #286 was to tentatively add the next entry's aspect ratio, without buffering it in buildingRow yet, to determine if that'd push us below the rowHeight, and if so, flush the row before that next entry, thereby treating the rowHeight like a minimum height.
In other words, before #286, we'd flush the row BEFORE adding the entry that would push us below the configured rowHeight, but after #286, we'd flush the row AFTER adding the entry that pushed us below the rowHeight.
The root source of the doubled margin was flushing a row with no buffered entries (hence increasing the offset without actually rendering a row). Given an empty buffered entries (start of a new row), if the entry being analyzed had an aspect ratio that'd make it's height less than the configured rowHeight, we'd flush the row BEFORE buffering the entry, thereby flushing an empty row.
Now, we only attempt to flush the row if we have at least one buffered entry.
This should still fix #223 and #275 without introducing the side-effects described above.
PR #286 attempted to fix a doubled margin between rows, however in my use case, while it solved that, it increased the images per row, thereby reducing the height of each image. Especially with a number of very wide, but short, images, this led each row to be significantly shorter then before #286.
I believe the source of that problem is that after #286, we'd buffer the next entry, add it's aspect ratio in the
buildingRow, then determine if thebuildingRow(while accounting for the aspect ratio a second time) was below therowHeightto flush the row, thereby treatingrowHeightlike a maximum height.It seems the intention prior to #286 was to tentatively add the next entry's aspect ratio, without buffering it in
buildingRowyet, to determine if that'd push us below therowHeight, and if so, flush the row before that next entry, thereby treating therowHeightlike a minimum height.In other words, before #286, we'd flush the row BEFORE adding the entry that would push us below the configured
rowHeight, but after #286, we'd flush the row AFTER adding the entry that pushed us below therowHeight.The root source of the doubled margin was flushing a row with no buffered entries (hence increasing the offset without actually rendering a row). Given an empty buffered entries (start of a new row), if the entry being analyzed had an aspect ratio that'd make it's height less than the configured
rowHeight, we'd flush the row BEFORE buffering the entry, thereby flushing an empty row.Now, we only attempt to flush the row if we have at least one buffered entry.
This should still fix #223 and #275 without introducing the side-effects described above.