Both 6° and 7.5° would be rather large increments between frames if the goal were to accurately depict the whole pattern's movement.

For a 400x700 image, the biggest circle which can entirely fit into the image would have a diameter of 400 pixels and thus a circumference of 1256.637 pixels. The distance from center to a corner is the hypotenuse of a 200x350 triangle, which is 403.113 pixels, so the smallest circle enclosing the whole thing (with that diagonal being its radius) would have a circumference of 2532.833 pixels. 6° would be a 60th of either circle, and 7.5° would be a 48th of it.

That means that any feature along the edges of the image must move between 26 and 53 pixels per frame-change if we use 7.5° increments, or between 20 and 43 pixels per frame-change if we use 6° increments. Depending on how you look at it, the little squares are 17 or 18 pixels tall and wide, which gives them diagonals of roughly 24 or 25 pixels, so the distance that each square must move near the edges exceeds the squares' length & width in any case and can be over three times as much at worst, and is barely even slightly under the diagonal length at best and more that twice as much at worst.

It's like trying to watch cars on the highway if they instantaneously teleport forward by two or three car lengths at a time, with other identical-looking cars behind them so that car A always has car B behind it but car B teleports into the space between car A's old and new locations. The discontinuity is bound to make you lose track of which cars are which.

I'm tempted to make a version with 1° or smaller increments between frames which rotates at the same rotational speed, but I suspect it will be too much work...