Makie.jl: surface `DimensionMismatch` error in AbstractPlotting v0.10.10

[grahamas]

surface fails when given axes with differing lengths. So the example works fine, but I've adapted it here to have differing axis lengths. The same code run with AbstractPlotting v0.10.9 works fine.

using Makie
NL = 30
NR = 31
function xy_data(x, y)
    r = sqrt(x^2 + y^2)
    r == 0.0 ? 1f0 : (sin(r)/r)
end
lspace = range(-10, stop = 10, length = NL)
rspace = range(-10, stop = 10, length = NR)

z = Float32[xy_data(x, y) for x in lspace, y in rspace]
l = range(0, stop = 3, length = NL)
r = range(0, stop = 3, length = NR)
surface(
    l, r, z,
    colormap = :Spectral
)

fails with

DimensionMismatch("arrays could not be broadcast to a common size; got a dimension with lengths 31 and 30")

Stacktrace:
 [1] _bcs1 at ./broadcast.jl:490 [inlined]
 [2] _bcs at ./broadcast.jl:484 [inlined]
 [3] broadcast_shape at ./broadcast.jl:478 [inlined]
 [4] combine_axes at /home/graham/.julia/packages/DiffEqBase/XoVg5/src/diffeqfastbc.jl:23 [inlined]
 [5] combine_axes at ./broadcast.jl:473 [inlined]
 [6] _axes at ./broadcast.jl:208 [inlined]
 [7] axes at ./broadcast.jl:206 [inlined]
 [8] eachindex at ./broadcast.jl:218 [inlined]
 [9] iterate(::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{2},Nothing,Type{Point{3,T} where T},Tuple{Array{Float32,1},Array{Float32,1},Array{Float32,2}}}) at ./broadcast.jl:229
 [10] isempty at ./essentials.jl:739 [inlined]
 [11] xyz_boundingbox(::Function, ::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{2},Nothing,Type{Point{3,T} where T},Tuple{Array{Float32,1},Array{Float32,1},Array{Float32,2}}}) at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/layouting/data_limits.jl:64
 [12] xyz_boundingbox(::Function, ::Array{Float32,1}, ::Array{Float32,1}, ::Array{Float32,2}) at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/layouting/data_limits.jl:81
 [13] atomic_limits(::Surface{...}) at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/layouting/data_limits.jl:21
 [14] data_limits at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/layouting/data_limits.jl:9 [inlined]
 [15] push!(::Scene, ::Surface{...}) at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/scenes.jl:360
 [16] plot!(::Scene, ::Type{Surface{...}}, ::Attributes, ::Tuple{Observable{StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}},Observable{StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}},Observable{Array{Float32,2}}}, ::Observable{Tuple{Array{Float32,1},Array{Float32,1},Array{Float32,2}}}) at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/interfaces.jl:643
 [17] plot!(::Scene, ::Type{Surface{...}}, ::Attributes, ::StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}, ::Vararg{Any,N} where N; kw_attributes::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{,Tuple{}}}) at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/interfaces.jl:571
 [18] plot!(::Scene, ::Type{Surface{...}}, ::Attributes, ::StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}, ::StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}, ::Array{Float32,2}) at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/interfaces.jl:540
 [19] surface(::StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}, ::Vararg{Any,N} where N; attributes::Base.Iterators.Pairs{Symbol,Symbol,Tuple{Symbol},NamedTuple{(:colormap,),Tuple{Symbol}}}) at /home/graham/.julia/packages/AbstractPlotting/ZOPv5/src/recipes.jl:15
 [20] top-level scope at In[11]:13

To rescue, just run ]add [email protected] [email protected]. (Reverting to AbstractPlotting v0.10.9 also requires reverting to GLMakie v0.1.2, but none of the function calls in the stacktrace refer to GLMakie [not sure what to make of DiffEqBase appearing in the stack...])

[asinghvi17]

This is the function that fails, since the dispatch is overly broad.

https://github.com/JuliaPlots/AbstractPlotting.jl/blob/de7fff85f6890c5a090758a232894ff29bd17f97/src/layouting/data_limits.jl#L80

@SimonDanisch this seems to have been introduced by the nonlinear transform changes. How should we handle this?

[asinghvi17]

The thought just came to me - we do also have to support matrices of x and y as well.

[SimonDanisch]

Jeez, I can't believe we dont have tests for this... Let me take a look!