Warning message of `arrows3d` with kwargs `rasterize` using `CairoMakie`

[ytdHuang]

• what version of Makie are you running? (]st -m Makie)
  Makie v0.24.5, CairoMakie v0.15.5
• can you reproduce the bug with a fresh environment ? (]activate --temp; add Makie)
  Yes, I created a new environment, added Makie and CairoMakie
• What platform + GPU are you on?
  Rocky Linux
• Which backend are you using? (GLMakie, CairoMakie, WGLMakie, RPRMakie)
  CairoMakie
• Please provide an minimal example of the failing code. If the problem is with the visualization, please provide a picture or video of it.

fig = Figure()
lscene = LScene(fig[1,1])

v = [1, 0, 1]
a3d = arrows3d!(lscene, Point3f(0), Point3f(v), rasterize = 3)

fig

The above code can be displayed, but there is an extra warning message:

Warning: Arrows3D{Tuple{Vector{GeometryBasics.Point{3, Float32}}, Vector{GeometryBasics.Point{3, Float32}}}} is not supported by cairo right now

If rasterize is set to be 0 or false, then the warning message disappeared.

Does this warning message (under rasterize != 0) make sense ? The figure displays the arrow correctly and everything seems normal.

[asinghvi17]

Was there a stack trace or a line number associated with that warning?

[ytdHuang]

@asinghvi17

@ CairoMakie /usr/local/julia-1.10.8/share/julia/packages/CairoMakie/mQKIJ/src/plot-primitives.jl:191

[ytdHuang]

(this is a kind reminder)

[ytdHuang]

Hi @asinghvi17
any thoughts on this ?

[ffreyer]

@ CairoMakie /usr/local/julia-1.10.8/share/julia/packages/CairoMakie/mQKIJ/src/plot-primitives.jl:191

Oh that's literally all it says. I thought this was one line of a larger trace.

This happens because a plot with rasterize != false is considered a primitive/atomic by

Makie.jl/CairoMakie/src/plot-primitives.jl

Line 67 in b245702

is_cairomakie_atomic_plot(plot::Plot) = Makie.is_atomic_plot(plot) || isempty(plot.plots) || to_value(get(plot, :rasterize, false)) != false

As a result the draw_plot() function may assume a recipe plot to be drawable as is and calls missing draw_atomic() function

Makie.jl/CairoMakie/src/plot-primitives.jl

Lines 131 to 146 in b245702

	function draw_plot(scene::Scene, screen::Screen, primitive::Plot)
	if to_value(get(primitive, :visible, true))
	if is_cairomakie_atomic_plot(primitive)
	Cairo.save(screen.context)
	draw_atomic(scene, screen, primitive)
	Cairo.restore(screen.context)
	end
	if !isempty(primitive.plots)
	zvals = Makie.zvalue2d.(primitive.plots)
	for idx in sortperm(zvals)
	draw_plot(scene, screen, primitive.plots[idx])
	end
	end
	end
	return
	end

which generates your warning.

The "draw everything in the scene/figure` function also lowers recipes into "primitive" plots to do z-sorting (of plots). Some recipes may rely on this to tweak the render order of their child plots.

Makie.jl/CairoMakie/src/plot-primitives.jl

Lines 14 to 15 in b245702

	allplots = Makie.collect_atomic_plots(scene; is_atomic_plot = is_cairomakie_atomic_plot)
	sort!(allplots; by = Makie.zvalue2d)

When drawing a rasterized recipe plot you don't want this disassembly to happen. Instead all the primitive plots belonging to a recipe plot should render together in a separate rasterized image. So rasterize != false is considered primitive to dodge the disassembly.

Pre #4630 this was fine because draw_plot() didn't rely on is_cairomakie_atomic_plot():

Makie.jl/CairoMakie/src/infrastructure.jl

Lines 131 to 145 in f06b984

	function draw_plot(scene::Scene, screen::Screen, primitive::Plot)
	if to_value(get(primitive, :visible, true))
	if isempty(primitive.plots)
	Cairo.save(screen.context)
	draw_atomic(scene, screen, primitive)
	Cairo.restore(screen.context)
	else
	zvals = Makie.zvalue2d.(primitive.plots)
	for idx in sortperm(zvals)
	draw_plot(scene, screen, primitive.plots[idx])
	end
	end
	end
	return
	end

This code was changed because text is now structured differently. Before #4630, text plots generally had a text -> text -> (text, linesegments) structure, where the lowest two plots contain relevant drawing information. (Linesegments is needed for latex strings.) Now the structure is text -> linesegments where both the parent and child are drawable. So isempty(plot.plots) is no longer valid to find atomics.

Not sure what to do about all of this. I'd lean towards removing the plot disassembly in the "draw everything" function, so that rasterized plots didn't need to be considered atomic. That would mean top level plots would be z-sorted relative to each other rather than their atomic child plots being sorted relatively to other atomic child plots.

[albertomercurio]

Hello, the similar thing happens for arrows2d. By following this example of the documentation

f = Figure(size = (500, 500))

a = Axis(f[1,1], aspect = DataAspect())
ps = [Point2f(cos(a), sin(a)) for a in range(0, 2pi, length=21)[1:end-1]]
scatter!(ps, marker = Circle, color = :transparent, strokewidth = 1)

# Double headed arrow between two points, filling half the distance with
# :center alignment
p = arrows2d!(
    ps, [ps[2:end]..., ps[1]], color = (:blue, 0.5),
    align = :center, lengthscale = 0.5, argmode = :endpoint,
    tail = Point2f[(0, 0), (1, -0.5), (1, 0.5)], taillength = 8
)

# arrow pointing away from ps with a 0.2 gap between the tail and ps
arrows2d!(
    ps, ps, color = eachindex(ps), align = -0.2,
    colormap = :rainbow, lengthscale = 0.5, rasterize=false
)

# arrow pointing to ps with a 0.2 gap between the tip and ps
arrows2d!(
    ps, ps, color = eachindex(ps), align = 1.2,
    colormap = :rainbow, lengthscale = 0.5, rasterize=false
)

f

I get a huge image, with a very bad quality.

If I set rasterize=true, the quality of the whole figure is better, but not the quality of the arrows, and I also see the warning message

┌ Warning: Arrows2D{Tuple{Vector{Point{2, Float32}}, Vector{Point{2, Float32}}}} is not supported by cairo right now
└ @ CairoMakie ~/.julia/packages/CairoMakie/F8YX7/src/plot-primitives.jl:191
┌ Warning: Arrows2D{Tuple{Vector{Point{2, Float32}}, Vector{Point{2, Float32}}}} is not supported by cairo right now
└ @ CairoMakie ~/.julia/packages/CairoMakie/F8YX7/src/plot-primitives.jl:191

[asinghvi17]

I would rather fix the pipeline...users can and do translate child plots in z to get "correct" layering. So IMO it is incorrect to not sort plots at the atomic level.

[ytdHuang]

Is there anyone willing to make a PR and fix this issue ?

I'm not familiar with Makie's code...

[ffreyer]

I would rather fix the pipeline...users can and do translate child plots in z to get "correct" layering. So IMO it is incorrect to not sort plots at the atomic level.

Hmm, now that I think about it, it would also not work for e.g. textlabel which typically z shifts in the recipe...

Hello, the similar thing happens for arrows2d. By following this example of the documentation

That renders without issues for me with rasterize = false. It's pretty big as an svg though at 1.3MB. I think because Cairo decides to rasterize the CairoMakie's mesh3d rendering. At least there are a bunch of image tags in there that look like arrow components

[ytdHuang]

(this is a kind reminder)