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

[RFC] Redesign the Drawable type #42

Open
johnnychen94 opened this issue Jul 23, 2020 · 4 comments
Open

[RFC] Redesign the Drawable type #42

johnnychen94 opened this issue Jul 23, 2020 · 4 comments
Labels

Comments

@johnnychen94
Copy link
Member

johnnychen94 commented Jul 23, 2020

The current ImageDraw design has significantly restricted its possibility to the 2D case, and that's not good in general (even though it's the most common case).

What I have in mind is:

abstract type Drawable end

struct Point{C<:Colorant, N} <: Drawable
    pos::CartesianIndex{N}
    color::C
    thickness::Int
end

struct Polygon{C<:Colorant, N, T<:CartesianIndex} <: Drawable
    vertices::NTuple{N, T}
    border_color::C
    border_width::Int
    fill_color::C
    fill::Bool # whether we need to fill the region with color C
end

struct Layers{A:: PriorityQueue} <: Drawable
    objects::A
end

Basically, each drawable type consists of the whole information on how it can be drawn.

Layers is a simple wrapper on DataStructures.PriortyQueue that controls how individual objects are drawn in one draw call.

Point is not serving as the index, but instead as a real physical "point" with color and thickness information.

This is a draft type design, we could definitely add more information into each drawable struct.

cc: @jiviteshjain @mgautam98

@johnnychen94 johnnychen94 changed the title Redesign the Drawable type [RFC] Redesign the Drawable type Jul 23, 2020
@johnnychen94
Copy link
Member Author

johnnychen94 commented Jul 23, 2020

This is so breaking a design that we may want to start a new repo to do this, a more appropriate place for this is in JuliaGraphics because Image is just one of many drawable types:

struct Image{A<:AbstractArray} <: Drawable
    # the axes of image contain all the positional information
    data::A
end

I could initialize it this weekend, in the meantime, we could still continue the devs here.

Edit:

I'm becoming rather ambitious that I'm now considering what graphic processing should be with image processing as one special case of it.

@kimikage
Copy link

https://xkcd.com/927/ 😄

Of course, I don't hate reinventing the wheel. My concerns are:

@johnnychen94
Copy link
Member Author

johnnychen94 commented Jul 24, 2020

Yes, this should start as an experiment and I'm not a graphic expert.

I really don't like the hard-coded x, y, width, height in those packages, given that we have much clearer CartesianIndex. Also, it's not a good experience when I get lost in the countless keyword arguments and names.

It should just start as an experimental package, and if it works well, I'll get ImageDraw deprecated.

@tp2750
Copy link

tp2750 commented Jun 19, 2022

This sounds very interesting @johnnychen94 . Did you start up a new repo?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants