Reviving CairoMakie/GLMakie integration #3652
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By separating the two concepts, we can create rasterized graphics at higher resolution than what is shown on screen. The window scale factor is used to scale the sizes of elements within the window (and on Linux and Windows, the window size itself from the requested logical sizes), and the px-per-unit scale factor dictates the size of the rasterized render.
This works around a crash that otherwise occurs when creating a screen directly with something like ```julia screen = GLMakie.Screen(resolution = (100, 100), visible = false) ``` I'm not sure why this is necessary, though, so that probably points at some subtle logic error in handling scaling factors and/or dimensions of windows and buffers.
so force the scale and px-per-unit factors to unity for the test.
This was causing problems with setting up the stream size for video outputs. Instead, just grab the scene size where necessary explicitly.
After identifying failing tests, closer reading suggests the line rendering shaders all work in normalized units that arise naturally from comparing the framebuffer size to resolution factor. This means adding additional scaling is unnecessary since the framebuffer size is already scaled.
- More explicit `range` to support older versions of Julia - Force a render of the figure before testing picking operations, since that doesn't happen implicitly when the sequence is not done with a visible plot interactively. - Use a less exact test for running within an Xvfb instance to support older versions of `xrdb` without the -get option.
- Clear the `scalefactor` and `px_per_unit` observables when the figure is closed. It's possible both may be used during a figure's lifetime, but that should not persist past a close. - In the system scale factor callback, do not unconditionally resize the native window. Instead, leverage the fact that the observable callback will invoke a resize event, and that correctly will check that the root scene is not `nothing`. At the same time, clean up other callbacks a little bit by making use of `Base.Fix1` to pass the associated screen through via a closure. - Do not completely ignore the scale factor on OSX. The difference is that there is a native scaling factor applied by the OS, but if/when the desired scale factor differs from the native scaling, we must still make adjustments.
Instead of polling for window size changes on every render tick, use the size-changed callback from GLFW to only make changes when it is known that there's been a change in the size of the window. This solves a concurrency problem that can happen when the scale factor is changed. The sequence of events looks like: 1. The `screen.scalefactor[]` value is changed 2. The listeners to `scalefactor` start to be notified. 3. Asynchronously, the `WindowAreaUpdater` listener attached to the `render_tick` observable runs. 4. The window area listener notices that the window size given the _new_ value of the scale factor doesn't match the scene size, so it updates the scene size. 5. The `scalefactor` listener responsible for resizing the window gets its slice of time to run, and it now sees that everything is already the "correct" size. Therefore, the window is not resized, and instead the scene size is rescaled in the opposite direction of the scale factor change.
technically, the `render_scene` hack is no longer used
Basically data space, without applying `apply_transform`. Works pretty well. MWE: ```julia fig, ax, plt = lines(1:10, 1:10; axis = (; xscale = log10)) lines!(ax, LinRange(0, 10, 10), 1:10; space = :transformed) ``` This is useful if you want to control when the plot's transform_func is applied, especially in a recipe!
asinghvi17
changed the title
This was referenced Aug 19, 2024
3 tasks
|
This PR seems to be pretty hopelessly out of date... I propose closing it, as we also have a few PRs like #4150, which will make this a bit easier. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft PR from my old GLMakie rasterization pipeline into CairoMakie.
As I recall, the issue was that displaying a child of the main Scene would cause that main Scene to resize to the size of the child's window, creating a loop of sorts. This was because scenes in a tree share the same events struct.
What I want to do here is figure out how to isolate or unlink the newly constructed screen from all events, so that subscenes can be displayed without resizing the main scene.