Breaking release 0.22

[ffreyer]

Description

PR for the next breaking release

Merge TODO:

• Updates for GeometryBasics refactor #4319
• Change automatic color generation for Voronoiplot #4357
• Metamesh and multi mesh loading #4496 (originally Make Makie.mesh compatible with MultiMesh (GeometryBasics refactor) #4368)
• rename Tesselation -> Tessellation #4564
• maybe Improve and use shared_attributes for attribute passthrough #4399 (waiting on plot update refactor)
• Split marker_offset from quad_offset #4594
• Add transform_marker attribute to meshscatter #4606
• Add zooming & translation controls to Axis3 #4131

To fix:

• partially reversed 2x2 surface fails surface(210..180, 80..110, rand(2, 2)) in WGLMakie (picking test)

Closes CompatHelper prs:
closes #4634, closes #4628, closes #4623, closes #4622, closes #4620, closes #4616, closes #4610, closes #4605, closes #4600

Actual Issues:

• fixes Some triangles are not rendered #3561
• fixes Order of decomposes coordinates is not counter/clockwise #2181 (2D primitives are now counter clockwise)
• closes Color uniform per element #1369 (FaceViews offer a way to do per-face colors)
• fixes voronoiplot default colours depend too much on the generator order #4344
• fixes Scatter marker_offset is broken #4383

[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(fig)

	using	create	display	create	display
GLMakie	5.91s (5.73, 6.31) 0.14+-	170.05ms (160.92, 203.64) 8.96+-	0.69s (0.63, 1.41) 0.17+-	6.96ms (6.72, 8.21) 0.31+-	25.96ms (25.44, 26.90) 0.38+-
master	6.42s (6.20, 6.71) 0.14+-	166.19ms (158.95, 192.57) 7.59+-	486.09ms (465.81, 515.90) 15.40+-	7.05ms (6.79, 7.81) 0.29+-	25.98ms (25.48, 26.67) 0.39+-
evaluation	1.09x faster✅, -0.51s (-3.54d, 0.00p, 0.14std)	0.98x invariant, 3.86ms (0.46d, 0.15p, 8.28std)	0.71x slower❌, 0.2s (1.66d, 0.00p, 0.09std)	1.01x invariant, -0.09ms (-0.31d, 0.33p, 0.30std)	1.00x invariant, -0.01ms (-0.03d, 0.93p, 0.39std)
CairoMakie	5.74s (5.58, 6.01) 0.13+-	174.02ms (162.59, 194.95) 10.41+-	201.91ms (192.25, 217.45) 8.23+-	6.78ms (6.57, 7.36) 0.20+-	1.04ms (1.01, 1.08) 0.02+-
master	5.99s (5.85, 6.31) 0.11+-	165.35ms (158.33, 179.68) 5.74+-	202.61ms (194.09, 219.94) 6.72+-	6.85ms (6.66, 7.42) 0.20+-	1.08ms (1.04, 1.18) 0.03+-
evaluation	1.04x faster ✓, -0.25s (-2.06d, 0.00p, 0.12std)	0.95x slower X, 8.67ms (1.03d, 0.00p, 8.08std)	1.00x invariant, -0.7ms (-0.09d, 0.77p, 7.47std)	1.01x invariant, -0.07ms (-0.36d, 0.26p, 0.20std)	1.04x faster ✓, -0.04ms (-1.58d, 0.00p, 0.02std)
WGLMakie	5.99s (5.81, 6.14) 0.10+-	169.47ms (164.03, 177.90) 4.53+-	6.15s (5.92, 6.34) 0.10+-	10.47ms (10.02, 11.09) 0.27+-	147.72ms (144.27, 151.85) 1.83+-
master	6.57s (6.42, 6.97) 0.15+-	164.68ms (158.04, 181.54) 5.52+-	5.94s (5.77, 6.44) 0.15+-	10.77ms (10.20, 12.91) 0.68+-	146.99ms (143.11, 150.63) 1.49+-
evaluation	1.10x faster✅, -0.59s (-4.61d, 0.00p, 0.12std)	0.97x slower X, 4.79ms (0.95d, 0.00p, 5.03std)	0.97x slower X, 0.21s (1.63d, 0.00p, 0.13std)	1.03x invariant, -0.3ms (-0.59d, 0.08p, 0.47std)	1.00x invariant, 0.73ms (0.43d, 0.18p, 1.66std)

[MakieBot]

Benchmark Results

SHA: f8e55192677fca9661c82932252f55417f1c4a5d

Warning

These results are subject to substantial noise because GitHub's CI runs on shared machines that are not ideally suited for benchmarking.

[ffreyer]

One of the failures here is that render order of the Axis3 framelines has changed in CairoMakie:

old	new

This is the case for all Axis3 refimages and also on master. I updated this one refimage for now.

[SimonDanisch]

This is the case for all Axis3 refimages and also on master.

Wait isn't that a regression, that was only recently reported?
Seems to me like we should try to figure out what's going on instead of updating the reference images. Or am I missing something?

[ffreyer]

Idk if it has been reported. I just updated the refimg here because it has nothing to do with the breaking release

[ffreyer]

Reverted the refimg update after merging #4591

The display times show opposite behavior for me locally. With

using GLMakie
macro ctime(x)
    return quote
        tstart = time_ns()
        $(esc(x))
        Float64(time_ns() - tstart)
    end
end
fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true);
GC.gc()
@ctime display(fig)

I get ~630ms on master and ~380ms on this branch. Number of stale instances also went down

[SimonDanisch]

I can confirm this! Really weird, considering that I should be using the same Julia version and this regression popping up quite reproducible on the CI.
It's pretty suspicious, that the numbers on the CI seem to match my local numbers quite closely, but the other way around.
I did check the using times as well, but they seem to match pretty well with what the CI measures, so those aren't flipped...
Not sure what's going on here, I guess it would be interesting to upload the tinv flamegraphs for the compile time benchmarks, since they show most accurately what's going on.