Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use concrete type instead of abstract Point2 #23

Merged
merged 5 commits into from
Dec 10, 2024

Conversation

thomvet
Copy link
Contributor

@thomvet thomvet commented Nov 20, 2024

Should address #22

Key change is that a concrete type Point2f is used for the datapoints in scatter (and axis) instead of the abstract type Point2. This essentially led to an Any type ending up somewhere down in the Makie stack where it didn't belong.

@thomvet
Copy link
Contributor Author

thomvet commented Nov 20, 2024

@stelmo @theogf I think this fixes the reported issue (#22); would be ready for merging in my opinion. + registering the bugfix release would be great.

Copy link
Contributor

@theogf theogf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix! This might even help with performance!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not create a new file specific to issues, it might be better to append it to the reference tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to have only tests that compare produced plots/images against reference images in the referencetests.jl file to keep the different types of tests separate, but I would of course be fine to move them if you insist :)

test/issues.jl Outdated Show resolved Hide resolved
test/issues.jl Outdated Show resolved Hide resolved
@thomvet
Copy link
Contributor Author

thomvet commented Nov 25, 2024

Struggling a little with the image sizes still. It seems to be dependent on what display one is working.

#Somehow fig seems to get converted in AbstractArray{<:Colorant} of different sizes, depending on
#what display is used; the function below is a workaround through file saving/loading. Not
#elegant, but it works.
function save_load_remove(fig)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked on Slack and one can use colorbuffer(fig) to directly get a Matrix of Colorant.

Copy link
Contributor Author

@thomvet thomvet Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but at least when I am testing it locally, I get the wrong size of matrix out. Doing:

fig = Figure(size = (900, 600), px_per_unit = 2)
arr = colorbuffer(fig)

I would have expected an array of 1800 x 1200 pixels, but I am getting a 900×1350 PermutedDimsArray(view(::Array{RGB{N0f8},2}, :, 900:-1:1), (2, 1)) with eltype ColorTypes.RGB{FixedPointNumbers.N0f8} returned to me.

Furthermore, what I am getting back is dependent on what display/monitor I am having the figure open on! I have two monitors: monitor 1 gives the above. When I move the same figure and run arr = colorbuffer(fig) again, I am getting a 604 x 907 matrix. Monitor 1 is landscape, monitor 2 is portrait.

That kind of made me move in the direction of a workaround...

Is there a direct and robust way of doing this correctly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm let me ask again on Slack if there is a standard way to do this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But anyway that's off topic from this MR. Let's just get this merged and we can apply an eventual better solution in a separate MR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solution seems to be colorbuffer(fig; px_per_unit=2) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a new commit; needed some more tweaking, but I think this version is cleaner than before.

@stelmo
Copy link
Owner

stelmo commented Dec 10, 2024

Hi guys, sorry for being permanently afk on this repo. This PR looks good to me, I will merge it and release. Thanks for helping out here!

@stelmo stelmo merged commit 8fa0c4f into stelmo:master Dec 10, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants