Performance benchmarks:

I believe the transpose operation in the MPL code is correct and shouldn't be removed. It changes the data from W x H, which is what Mesa uses, to H x W, what is what imshow uses. I don't think the matplotlib backend is flipped in its current form. Rather, since you said "according to data", I think you may be reading the sugarmap.txt file (and asymmetrical edited versions of it) incorrectly.

It's confusing because Mesa arranges PropertyLayer values in W x H arrays. This means the row is x and the column is y. I think it's good that Mesa does it this way, I wouldn't change it, but it can lead to confusion if you try to look at the sugarmap.txt file in order to understand how the data should look on screen. You don't usually expect to read x from top to bottom and y from left to right, but this is how the data is laid out in the PropertyLayers. (I may be totally wrong in my assumptions about how you're reading the data -- I'm just basing it off my own experience when I was trying to understand the same thing. It would be helpful to see the original .txt file you're using for your matplotlib examples.)

This might seem like just a matter of perspective, but it's not, because the width vs. height distinction is extremely important. If you edit your examples to something with differing width and height (it's easy to edit it to 40x50), honestly I'm not totally sure but I think it will either look wrong once you run it or just break the visualization entirely.

With the Altair code, I'm not sure but I think the y-coordinates are reversed and the x coordinates are fine. You have an earlier version of this PR that looks like it might work.

Sorry for not replying, was busy for a few days and thanks for pointing it out, I'll try cross checking with the older version of mesa.

I think this should address the problem, in the end the data was flipped vertically, I've also compared it with the mesa 3.2 version, and yeah the data is originally mapped from W x H to H x W which is indeed confusing.

Sorry for not replying, was busy for a few days and thanks for pointing it out, I'll try cross checking with the older version of mesa.

No worries! Glad I could help. The coordinate layout stuff is super hard to think about IMO.

@tpike3 since you’re most familiar with the Sugerscape example, can you give this a review?

For me the most important thing is Mesa is internally consistent. Regardless of Altair or Matplotlib users should expect to find the origin in the same spot. The lat/long switches on GIS libraries have caused me no end of issues.

So I wholeheartedly approve of this fix.

With this approval, once you're ready, I can believe you can now merge yourself :)
(highly recommend squashing while merging)

We released Mesa 3.3.1 with this bugfix, so you should now be able to update Mesa (pip install -U mesa) and have this bug resolved!