-
Notifications
You must be signed in to change notification settings - Fork 4
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
Conversation
There was a problem hiding this 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!
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :)
Struggling a little with the image sizes still. It seems to be dependent on what display one is working. |
test/referencetests.jl
Outdated
#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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
?
There was a problem hiding this comment.
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.
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! |
Should address #22
Key change is that a concrete type
Point2f
is used for the datapoints in scatter (and axis) instead of the abstract typePoint2
. This essentially led to anAny
type ending up somewhere down in the Makie stack where it didn't belong.