fix changing input types

[SimonDanisch]

Incredibly enough, nobody seems to have run into this in a long time...
Seems like changing input types is pretty unpopular.
Changing types after convert_arguments isn't expected to work, since that usually changes plot type, but changing the input type to convert_arguments should have been working. Might have regressed in some of the observable refactors.

[MakieBot]

Compile Times benchmark

Note, that these numbers may fluctuate on the CI servers, so take them with a grain of salt. All benchmark results are based on the mean time and negative percent mean faster than the base branch. Note, that GLMakie + WGLMakie run on an emulated GPU, so the runtime benchmark is much slower. Results are from running:

using_time = @ctime using Backend
# Compile time
create_time = @ctime fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @ctime Makie.colorbuffer(display(fig))
# Runtime
create_time = @benchmark fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @benchmark Makie.colorbuffer(display(fig))

	using	create	display	create	display
GLMakie	14.84s (14.77, 15.03) 0.09+-	18.12s (18.01, 18.17) 0.05+-	17.05s (16.95, 17.13) 0.06+-	14.53ms (14.41, 14.72) 0.11+-	92.33ms (91.71, 93.51) 0.60+-
master	14.90s (14.87, 14.98) 0.04+-	18.31s (18.16, 18.52) 0.12+-	16.86s (16.79, 16.95) 0.05+-	14.65ms (14.39, 14.93) 0.17+-	92.91ms (92.45, 93.65) 0.42+-
evaluation	-0.41%, -0.06s invariant (-0.87d, 0.14p, 0.06std)	-1.05%, -0.19s faster ✓ (-2.12d, 0.00p, 0.08std)	+1.11%, 0.19s slower X (3.44d, 0.00p, 0.05std)	-0.77%, -0.11ms invariant (-0.79d, 0.17p, 0.14std)	-0.62%, -0.58ms invariant (-1.11d, 0.06p, 0.51std)
CairoMakie	12.52s (12.36, 12.73) 0.14+-	18.65s (18.41, 19.00) 0.18+-	3.06s (3.00, 3.10) 0.04+-	15.06ms (14.80, 15.40) 0.19+-	25.64ms (25.46, 25.84) 0.17+-
master	12.67s (12.38, 12.93) 0.20+-	18.95s (18.70, 19.17) 0.21+-	3.08s (3.01, 3.16) 0.05+-	15.44ms (15.22, 15.87) 0.23+-	25.96ms (25.49, 26.68) 0.39+-
evaluation	-1.24%, -0.16s invariant (-0.91d, 0.12p, 0.17std)	-1.62%, -0.3s faster ✓ (-1.54d, 0.01p, 0.20std)	-0.67%, -0.02s invariant (-0.46d, 0.41p, 0.04std)	-2.55%, -0.38ms faster ✓ (-1.81d, 0.01p, 0.21std)	-1.22%, -0.31ms invariant (-1.03d, 0.09p, 0.28std)
WGLMakie	23.69s (22.76, 24.16) 0.47+-	31.79s (31.37, 32.25) 0.27+-	53.17s (52.29, 55.73) 1.20+-	30.76ms (29.27, 34.97) 1.90+-	1.93s (1.86, 1.96) 0.04+-
master	23.64s (22.86, 24.86) 0.67+-	32.85s (32.37, 34.00) 0.55+-	53.23s (52.62, 54.51) 0.78+-	31.32ms (29.94, 32.24) 0.90+-	1.95s (1.90, 2.00) 0.03+-
evaluation	+0.23%, 0.06s invariant (0.10d, 0.86p, 0.57std)	-3.33%, -1.06s faster ✓ (-2.43d, 0.00p, 0.41std)	-0.13%, -0.07s invariant (-0.07d, 0.90p, 0.99std)	-1.83%, -0.56ms invariant (-0.38d, 0.50p, 1.40std)	-1.12%, -0.02s invariant (-0.62d, 0.27p, 0.04std)

[lazarusA]

This looks like #2204, although is for WGLMakie, so it might be a completely different issue. Well, it was working with GLMakie, so indeed is a different thing.

[SimonDanisch]

It's quite the different issue ;)