-
Notifications
You must be signed in to change notification settings - Fork 10
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
[RFC] Generalize some fallbacks #29
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #29 +/- ##
==========================================
- Coverage 45.25% 41.89% -3.37%
==========================================
Files 1 1
Lines 137 148 +11
==========================================
Hits 62 62
- Misses 75 86 +11
Continue to review full report at Codecov.
|
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.
LGTM
@@ -672,8 +682,12 @@ source color. | |||
@mustimplement set_source(gc::GraphicsContext, src) | |||
|
|||
function set_source(gc::GraphicsContext, c::Color) | |||
rgb = convert(RGB, c) | |||
set_source_rgb(gc, rgb.r, rgb.g, rgb.b) | |||
c isa AbstractRGB && return set_source_rgb(gc, red(c), green(c), blue(c)) |
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.
Maybe slightly cleaner with dispatch but no big deal either way
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 almost forgot the original intent, but the specialization can introduce ambiguity in the backend implementations.
Of course, it is possible to dispatch "private" methods.
|
||
Transform a coordinate `c` from the device space to the user space. | ||
|
||
See also: [`device_to_user`](@ref), [`user_to_device!`](@ref) | ||
""" | ||
device_to_user!(gc::GraphicsContext, c::Vector{Float64}) = c # TODO: generalization | ||
function device_to_user!(gc::GraphicsContext, c::AbstractVector{T}) where T <: Real | ||
length(c) == 2 || throw(ArgumentError("Only 2-D vectors are supported.")) |
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.
length(c) == 2 || throw(ArgumentError("Only 2-D vectors are supported.")) | |
length(c) == 2 || throw(ArgumentError("Only length-2 vectors are supported.")) |
|
||
Transform a coordinate `c` from the user space to the device space. | ||
|
||
See also: [`user_to_device`](@ref), [`device_to_user!`](@ref) | ||
""" | ||
user_to_device!(gc::GraphicsContext, c::Vector{Float64}) = c # TODO: generalization | ||
function user_to_device!(gc::GraphicsContext, c::AbstractVector{T}) where T <: Real | ||
length(c) == 2 || throw(ArgumentError("Only 2-D vectors are supported.")) |
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.
length(c) == 2 || throw(ArgumentError("Only 2-D vectors are supported.")) | |
length(c) == 2 || throw(ArgumentError("Only length-2 vectors are supported.")) |
IMO, it is better to add tests before making any changes. However, implementing a new backend for testing is not very productive, and it may contain bugs. |
When I was working on PR #22, I thought some of the fallbacks weren't pretty good.
However, as it stands, Graphics.jl does not really play a role as an abstraction layer, so I have doubts about the necessity of making these changes.