Force colorbuffer to use the size of the screen, not the scene #2012
Conversation
This allows arbitrary scaling in CairoMakie, remains constant in GLMakie, and probably breaks WGLMakie.
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 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))
|
|
I don't really understand where in the code the |
|
Hmm, that's a good idea - might require a bit of refactor but will do that. The px_per_unit is in this case read from the backend in |
for CairoMakie
| - Recording and colorbuffers use screen size instead of scene size, allowing e.g. the `px_per_unit` argument in CairoMakie to take effect. | ||
| It is sufficient to set the global `px_per_unit` setting by calling `CairoMakie.activate!(px_per_unit=3)` or whichever scaling factor is desired. | ||
| - Recording and colorbuffers use screen size instead of scene size, allowing e.g. the `px_per_unit` argument in CairoMakie to take effect. | ||
| It is sufficient to set the global `px_per_unit` setting by calling `CairoMakie.activate!(px_per_unit=3)` or whichever scaling factor is desired. |
There was a problem hiding this comment.
Is that a change in behavior? I'm not sure if the CairoMakie.activate!(... settings were proliferated to save before. Do we want them to or not?
|
closed in favor of #2306 |
Description
This also changes the VideoStream constructor similarly, allowing the user to use patterns like this:
This works with GLMakie and CairoMakie, but will probably break WGLMakie since there seems to be no
GeometryBasics.widthdefinitions for either WGLDisplay or ThreeDisplay, and I'm not sure how to go about implementing those since the display structs don't contain their Scenes directly.I built this off my other PR which accelerates recording speed in the presence of rasterized plots, but will rebase once that is merged.
Type of change
Delete options that do not apply:
Checklist