Allow CairoMakie to use GLMakie to rasterize plots #2061
Conversation
asinghvi17
force-pushed
the
as/cairo_glmakie
branch
from
8ebb191 to
8c8441c
Compare
Compile Times benchmarkNote, 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 master. 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))
|
|
This will have to wait for #2544, because it otherwise has scaling issues. However, if that is merged, this should be smooth sailing! |
|
This branch is pretty outdated, I have another one which is based off the GL-hidpi branch which might give us some better results. The central issue there is that scenes in a tree share events, so if I display a non-root scene in a different window, that window area propagates to the root scene, which causes a loop of resizing which makes the scene smaller until it reaches 1x1px. We could fix this by having some mechanism (standardized kwarg to |
Description
Using @jkrumbiegel's proposed alpha-colorbuffer by comparing the same scene with white v/s black background, we can obtain an image with transparency from GLMakie.
Basically, this is intended to use the same idea as the previously implemented
rasterizefeature, but instead of rendering to an image using Cairo, it renders using a given backend (usually GLMakie). This means that complex 3D plots like volumes or complicated meshes can be rendered (a) more efficiently and (b) more accurately (using features like depth buffering) if the user wishes it. However, line widths, marker sizes and text sizes are all reduced by1/scale, because there is no change to pixel space. This could theoretically be addressed by going down to the atomic level and changing plots around, but that seems somewhat unsustainable. It could be an optional feature, though.One could also render entire Scenes in order to obtain true 3d rendering.
The syntax for the plot rendering is
rasterize = (backend::Module, scale::Int).backendmust define anactivate!()method. It's not the best interface right now, but I suppose that would have to wait until the display stack gets refactored, so that we could just cache a screen instead.Internally, this works by manually creating a new Scene of resolution
widths(pixelarea(scene)[]) .* scale), whose camera and transformation are then overridden.Note that this is still a very experimental feature, and I haven't updated the code for the new GLMakie multi-screen feature yet.