Fix invalid range logscale

[fatteneder]

Description

Fixes #1670

Avoid equal axis limits and fall back to default ones.

I also modified validate_limits_for_scale to error if equal axis limits are encountered even if no log scale is set. Is this ok?
Previously this did not error on standard axis, e.g.

lines(1:10,1:10, axis=(; limits=(1,1,1,5))

worked.

Should I also add units test for this?

Type of change

Delete options that do not apply:

• Bug fix (non-breaking change which fixes an issue)

Checklist

• Added unit tests for new algorithms, conversion methods, etc.

[fatteneder]

Just noted that running the MWE from #1670 now gives also an empty plot, because the data lies outside of the default range.
Should I also address this in this PR?

[SimonDanisch]

Thank you! :)
Looks like the text annotation is gone too in the tests:

[fatteneder]

I looked into issue with the annotations.
Indeed, the problem is caused by the changes of this PR.
However, I am not sure whether the logic before that was even ok.

Consider this part of the code https://github.com/JuliaPlots/Makie.jl/blob/559416f27363519dde25b5faea79fd201131cbd6/src/makielayout/layoutables/axis.jl#L751-L772
and add a display(boundingbox) statement and rerun the test:

julia> text(". This is an annotation!", position=(300,200))
GeometryBasics.HyperRectangle{3, Float32}(Float32[300.0, 200.0, 0.0], Float32[0.0, 0.0, 0.0])
GeometryBasics.HyperRectangle{3, Float32}(Float32[300.0, 200.0, 0.0], Float32[0.0, 0.0, 0.0])

This suggests that the text box's origin is [300,200,0] and width is [0,0,0]. Because maximum, minimum are overloaded as origin, origin + width, respectively, we find equal axis limits, which this PR tries to avoid.

Q1: Is zero width for text boxes intended or a bug?
Q2: If it is a bug, should I open a new issue and resolve it there first?

[fatteneder]

Just read the docs at https://makie.juliaplots.org/v0.15.1/examples/layoutables/axis/index.html and it says that

You can set axis limits with the functions xlims!, ylims! or limits!. The numbers are meant in the order left right for xlims!, and bottom top for ylims!. Therefore, if the second number is smaller than the first, the respective axis will reverse.

So it seems like equal axis limits should not be ruled out or? Could somebody please confirm?

If so, then the solution for #1670 has to be different.

[jkrumbiegel]

Limits where min == max should not be allowed, it doesn't make sense as all projection math in the scene breaks down in that case. It probably breaks down much earlier if we have really small distances between min and max, but I guess that is a different issue.

I have to check the logic again to make sure that the point where the equal limits are checked is the earliest-possible point, so that all logic behind that can assume non-zero-width limits. In principle, a zero width boundingbox for a plot is fine (as in the annotation case), that just means there's only one data point (the anchor of the text). But this can't proliferate to the actual axis limits. It shouldn't, as I have logic in the autolimits function that expands zero-width auto limits, I'll have to check this specific case here.

[fatteneder]

Thanks for the clarification.

... It probably breaks down much earlier if we have really small distances between min and max, but I guess that is a different issue.

I think that is actually happening in #1670, which lead to this PR.

[SimonDanisch]

Closing in favor of #3077