Makie.jl
Makie.jl copied to clipboard
Hexbin recipe (continuation of 2201)
continuation of https://github.com/JuliaPlots/Makie.jl/pull/2201/
poly updates still fail, probably related to a similar problem with contourf
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 | 21.02s (19.85, 22.33) 0.84+- | 22.88s (21.61, 24.71) 1.10+- | 21.49s (20.32, 23.18) 1.01+- | 24.43ms (23.77, 25.19) 0.45+- | 131.80ms (129.87, 134.26) 1.54+- |
master | 21.17s (19.84, 22.00) 0.67+- | 22.82s (21.55, 24.45) 0.89+- | 21.58s (20.74, 22.20) 0.54+- | 24.55ms (23.69, 24.96) 0.42+- | 132.52ms (129.85, 136.77) 2.25+- |
evaluation | -0.69%, -0.15s invariant (-0.19d, 0.73p, 0.75std) | +0.27%, 0.06s invariant (0.06d, 0.91p, 1.00std) | -0.45%, -0.1s invariant (-0.12d, 0.83p, 0.77std) | -0.45%, -0.11ms invariant (-0.25d, 0.65p, 0.44std) | -0.55%, -0.72ms invariant (-0.37d, 0.50p, 1.90std) |
CairoMakie | 19.01s (18.78, 19.42) 0.23+- | 26.95s (26.15, 27.48) 0.45+- | 4.38s (4.30, 4.43) 0.05+- | 27.08ms (26.01, 27.99) 0.60+- | 33.24ms (32.49, 33.69) 0.46+- |
master | 19.01s (18.78, 19.32) 0.24+- | 26.96s (26.19, 27.54) 0.47+- | 4.41s (4.23, 4.58) 0.13+- | 27.18ms (26.52, 27.61) 0.41+- | 32.89ms (32.58, 33.52) 0.34+- |
evaluation | -0.02%, -0.0s invariant (-0.01d, 0.98p, 0.24std) | -0.05%, -0.01s invariant (-0.03d, 0.96p, 0.46std) | -0.66%, -0.03s invariant (-0.29d, 0.61p, 0.09std) | -0.38%, -0.1ms invariant (-0.20d, 0.72p, 0.50std) | +1.05%, 0.35ms invariant (0.86d, 0.13p, 0.40std) |
WGLMakie | 26.77s (26.19, 27.23) 0.37+- | 35.49s (33.94, 37.62) 1.24+- | 59.42s (56.92, 62.06) 1.76+- | 32.33ms (30.55, 33.81) 1.22+- | 2.04s (2.00, 2.08) 0.03+- |
master | 26.55s (25.84, 27.54) 0.63+- | 35.81s (34.30, 37.29) 1.11+- | 59.49s (56.55, 63.66) 2.47+- | 32.48ms (31.69, 33.06) 0.49+- | 2.06s (2.01, 2.08) 0.02+- |
evaluation | +0.80%, 0.21s invariant (0.41d, 0.46p, 0.50std) | -0.91%, -0.32s invariant (-0.28d, 0.62p, 1.18std) | -0.12%, -0.07s invariant (-0.03d, 0.95p, 2.12std) | -0.47%, -0.15ms invariant (-0.16d, 0.77p, 0.86std) | -0.98%, -0.02s invariant (-0.74d, 0.19p, 0.03std) |
I cleaned up code and docs, tests are still needed.
The thing that I'm still unsure about is what bins
and binsize
should mean. Because of the inherent asymmetry in x and y, it's not so easy to choose. Currently, one "bin" means one step from center to center for me (so at least two hexagons) because when you want to cover a rectangular area with hexagons, you need to cut half of the hexagons in half and they'll stick out. So it seems sensible to me to go from center left to center right in steps of adjacent centers.
Missing reference images
Found 7 new images without existing references. Upload new reference images before merging this PR.
This only fails on WGLMakie because highclip
and lowclip
are nothing
by default (forwarded to Scatter) and WGLMakie doesn't seem to like that. I thought scatter supported those already? But if it was supposed to, it was not covered by tests.
We should probably document this better, but things that need to be calculated somewhere (e.g. backend) , should be set to automatic instead of nothing!
Missing reference images
Found 6 new images without existing references. Upload new reference images before merging this PR.
Missing reference images
Found 6 new images without existing references. Upload new reference images before merging this PR.
Missing reference images
Found 6 new images without existing references. Upload new reference images before merging this PR.
Thanks @jkrumbiegel & @TabeaW, this looks really great :)