[ANN] Makie v0.20

jules · November 22, 2023, 11:28am

The latest Makie version has been in the works for about a year, and now it’s finally here. It includes many new features, bug fixes and internal improvements, such as high-DPI support for GLMakie and WGLMakie, faster time-to-first-plot, a new experimental declarative API as well as multi-light rendering and improvements to Makie’s default lighting.

Have a look at blog.makie.org/blogposts/v0.20 where we describe all these developments in detail, and how you can upgrade your old code. (For the most part, it should still run, just with deprecation warnings).

A big thank you to all contributors and sponsors that have made this release possible! We hope you enjoy it and are looking forward to seeing how you will put it to good use. Happy plotting!

The Makie dev team
Simon, Julius and Frederic

Datseris · November 22, 2023, 11:49am

Congratulations on the new release! It appears to be a huge amount of work! I am looking forwards to a faster and more powerful makie!

I read through the new Spec API section of the blogpost. But I admit, I did not understand it. That’s okay though, it doesn’t appear to target my use cases (…?), but rather developers that build on Makie.

What I am mainly concerned with is whether the current standard way that I use makie, by initializing axis, and adding plots to axis with e.g., scatter! is subject to change. That was not clear from the blog post. I have to admit, the “old” way is simpler from a perspective of how much code I have to write and how many different names (of functions and structs) I have to use in the code. So I am hoping that the new API won’t replace the old usage, because the average user may favor the simpler usage over the more power of the new api.

jules · November 22, 2023, 11:52am

What I am mainly concerned with is whether the current standard way that I use makie, by initializing axis, and adding plots to axis with e.g., scatter! is subject to change

It does not change. The spec api is for

making recipes that change plot types dynamically
making recipes that create assemblies of axes, colorbars, etc. (although it’s not a full solution to that problem space)
making complex animations with only one high-level observable
having a descriptor format for figures that could help with serialization in the future
bringing us a step closer to better interop with Pluto

LaurentPlagne · November 22, 2023, 12:16pm

Terrific release ! Thank you so much for all this work.

quick question : what if the new command for

   GLMakie.set_window_config!(;float=true)

?

jules · November 22, 2023, 12:20pm

I think you pass those in GLMakie.activate! these days. I’ll have to check when that was removed and if it should get a deprecation warning.

LaurentPlagne · November 22, 2023, 12:25pm

Perfect ! I have been able to get rid of one remaining warning in no time (resolution → size).
Thank you again !

sdanisch · November 22, 2023, 1:59pm

This has been deprecated for a long time.
The note about this is at the end of the blogpost:

LaurentPlagne · November 22, 2023, 2:09pm

Good to know.
For some reason, I did not get warning with the previous version.

sdanisch · November 22, 2023, 2:17pm

That’s why there is a reminder about how Julia’s depwarns work in the first sentence:
If you haven't run Makie with julia --depwarn=true previously

LaurentPlagne · November 22, 2023, 2:26pm

Ah, sorry. I thought depwarn=true was the default.

LaurentPlagne · November 22, 2023, 2:40pm

It seems to be julia --depwarn=yes (not true)
Actually I do not see clearly what to do with the deprecation warnings since I do not use Makie.Combined or Makie.ContinuousSurface.

46 dependencies successfully precompiled in 89 seconds. 266 already precompiled.
  3 dependencies had output during precompilation:
┌ GLMakie
│  WARNING: Makie.Combined is deprecated, use Plot instead.
│    likely near none:1
│  WARNING: importing deprecated binding Makie.Combined into GLMakie.
│  , use Plot instead.
│  WARNING: Makie.ContinuousSurface is deprecated, use VertexGrid instead.
│    likely near none:1
│  WARNING: importing deprecated binding Makie.ContinuousSurface into GLMakie.
│  , use VertexGrid instead.
│  WARNING: Makie.DiscreteSurface is deprecated, use CellGrid instead.
│    likely near none:1
│  WARNING: importing deprecated binding Makie.DiscreteSurface into GLMakie.
│  , use CellGrid instead.
└  
┌ MakieCore
│  WARNING: Wrapping `Vararg` directly in UnionAll is deprecated (wrap the tuple instead).
│  You may need to write `f(x::Vararg{T})` rather than `f(x::Vararg{<:T})` or `f(x::Vararg{T}) where T` instead of `f(x::Vararg{T} where T)`.
│  WARNING: Wrapping `Vararg` directly in UnionAll is deprecated (wrap the tuple instead).
│  You may need to write `f(x::Vararg{T})` rather than `f(x::Vararg{<:T})` or `f(x::Vararg{T}) where T` instead of `f(x::Vararg{T} where T)`.
└  
┌ CairoMakie
│  WARNING: Makie.Combined is deprecated, use Plot instead.
│    likely near none:1
│  WARNING: importing deprecated binding Makie.Combined into CairoMakie.
│  , use Plot instead.
│  WARNING: Makie.ContinuousSurface is deprecated, use VertexGrid instead.
│    likely near none:1
│  WARNING: importing deprecated binding Makie.ContinuousSurface into CairoMakie.
│  , use VertexGrid instead.
│  WARNING: Makie.DiscreteSurface is deprecated, use CellGrid instead.
│    likely near none:1
│  WARNING: importing deprecated binding Makie.DiscreteSurface into CairoMakie.
│  , use CellGrid instead.

sdanisch · November 22, 2023, 2:46pm

Ah that’s a bit unfortunate… Since we re-export bindings in the backends, re-exporting the deprecation triggers a depwarn.
But without re-exporting it, it wouldn’t be a graceful deprecation -.-
So you should watch out for depwarns in your own Makie code

juliohm · November 22, 2023, 6:54pm

Congratulations on the new release!

We are trying to update our recipes, but for some reason the Makie.mesh function is not producing the expected results in 3D.

Consider the following mesh of triangles produced with the master branch of Meshes.jl:

julia> m = simplexify(boundary(Box((0,0,0), (1,1,1))))
12 SimpleMesh{3,Float64}
  8 vertices
  ├─ Point(0.0, 0.0, 0.0)
  ├─ Point(1.0, 0.0, 0.0)
  ├─ Point(1.0, 1.0, 0.0)
  ├─ Point(0.0, 1.0, 0.0)
  ├─ Point(0.0, 0.0, 1.0)
  ├─ Point(1.0, 0.0, 1.0)
  ├─ Point(1.0, 1.0, 1.0)
  └─ Point(0.0, 1.0, 1.0)
  12 elements
  ├─ Triangle(4, 3, 2)
  ├─ Triangle(4, 2, 1)
  ├─ Triangle(6, 5, 1)
  ├─ Triangle(6, 1, 2)
  ├─ Triangle(3, 7, 6)
  ⋮
  ├─ Triangle(4, 7, 3)
  ├─ Triangle(1, 5, 8)
  ├─ Triangle(1, 8, 4)
  ├─ Triangle(6, 7, 8)
  └─ Triangle(6, 8, 5)

With Makie.jl v0.19 we could simply call

Mke.plot(m)

Now, the recipe is producing a 2D view of the 3D mesh.

The underlying call can be reproduced with

julia> coords = coordinates.(vertices(m))
8-element Vector{Vec3}:
 Vec(0.0, 0.0, 0.0)
 Vec(1.0, 0.0, 0.0)
 Vec(1.0, 1.0, 0.0)
 Vec(0.0, 1.0, 0.0)
 Vec(0.0, 0.0, 1.0)
 Vec(1.0, 0.0, 1.0)
 Vec(1.0, 1.0, 1.0)
 Vec(0.0, 1.0, 1.0)

julia> connec = reduce(hcat, collect.(indices.(elements(topology(m))))) |> transpose
12×3 transpose(::Matrix{Int64}) with eltype Int64:
 4  3  2
 4  2  1
 6  5  1
 6  1  2
 3  7  6
 3  6  2
 4  8  7
 4  7  3
 1  5  8
 1  8  4
 6  7  8
 6  8  5

julia> GLMake.mesh(coords, connec)

Calling the Makie.mesh directly works fine. The problem only occurs when the function is called from within the recipe.

Any idea of what may be happening?

jules · November 22, 2023, 7:30pm

In the old version, Makie would find out in a kind of convoluted way what the data limits of a plot were and then pick a 3D or 2D axis depending on the result. That was slow and also had edge cases. Now it works with type based overloads, independent of limits. Mesh has the overload for the 3D axis but your recipe doesn’t. So you need to add it, it’s described in the blog post I think, currently on the phone and can’t check.

juliohm · November 22, 2023, 8:33pm

Thank you @jules . Appreciate if you can share the link when you get back to your workstation. I couldn’t find it easily in the blog post.

juliohm · November 22, 2023, 8:59pm

Even better would be a short tutorial explaining how to update recipes written in the previous version.

jules · November 23, 2023, 8:44am

It’s this part:

Ironically, this refactor removed the reliance on the first plots boundingbox for deciding which axis to use. Instead we now use this overloadable interface:
Makie.args_preferred_axis([PlotType], plot_arguments...) = PreferredAxisType
Makie.preferred_axis_type(plot::PlotType) = PreferredAxisType
# Which is used like this:
# Always use 3D axis for 3d points
Makie.args_preferred_axis(::AbstractVector{<:Point3}) = LScene
# Always use LScene for Volume plots
preferred_axis_type(::Volume) = LScene

juliohm · November 23, 2023, 10:29am

Thank you @jules, the following worked:

Makie.args_preferred_axis(::Geometry{Dim}) where {Dim} = Dim === 2 ? Makie.Axis : Makie.LScene

Consider renaming

LScene → Axis{3}
Axis → Axis{2}

in a future release.

sdanisch · November 23, 2023, 11:34am

Yeah LScene is ripe for a refactor & rename I quickly thought about doing it as part of 0.20, but then everything already took so long, that I didn’t want to postpone the release any longer.

hexaeder · November 23, 2023, 12:18pm

In GraphMakie the Axis type is determined by the layout, which is a keyword argument/Attribute of the plot. I tried to define a function like

Makie.args_preferred_axis(x::Plot{GraphMakie.graphplot}, plot_arguments...)

and hoped to get the Attributes from the plot_arguments. But this functions never gets called in the pipeline… is there a way to achieve this?

If the user uses the layouts provided by NetworkLayout, the dimensionality is statically derivable from the type of layout. However we allow for arbitrary functions as layout, so sometimes I’d need to explicitly evaluate the layout function to determine the axis type…