don't allow v2.5 of Luxor because of transposing

[Wikunia]

PR Checklist

If you are contributing to Javis.jl, please make sure you are able to check off each item on this list:

• I think the following points do not apply 😉

• Did I update CHANGELOG.md with whatever changes/features I added with this PR?

• Did I update the TODO.md (if applicable)?

• Did I make sure to only change the part of the file where I introduced a new change/feature?

• Did I cover all corner cases to be close to 100% test coverage (if applicable)?

• Did I properly add Javis dependencies to the Project.toml + set an upper bound of the dependency (if applicable)?

• Did I properly add test dependencies to the test directory (if applicable)?

• Did I check relevant tutorials that may be affected by changes in this PR?

• Did I clearly articulate why this PR was made the way it was and how it was made?

How did you address these issues with this PR? What methods did you use?
I've disallowed v2.5 of Luxor as it seems to handle image matrices differently. At one point we probably only want to support v2.5 and above though.

[codecov]

Codecov Report

Merging #149 into v0.2 will increase coverage by 0.32%.
The diff coverage is 99.27%.

@@            Coverage Diff             @@
##             v0.2     #149      +/-   ##
==========================================
+ Coverage   97.33%   97.66%   +0.32%     
==========================================
  Files           7        7              
  Lines         451      557     +106     
==========================================
+ Hits          439      544     +105     
- Misses         12       13       +1     

Impacted Files	Coverage Δ
src/Javis.jl	96.69% <98.92%> (+0.57%)	⬆️
src/luxor_overrides.jl	100.00% <100.00%> (ø)
src/subaction_animations.jl	100.00% <100.00%> (ø)
src/util.jl	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ed48738...8c703c2. Read the comment docs.

[Wikunia]

I'll merge this and we might revert back as @cormullion is going to put the transpose back into it probably tmr.

[cormullion]

I'm taking the transpose out, I thought?

[Wikunia]

Wait what? 😂 Does taking it out brings it back to v2.4 behavior or will it be a breaking change and you mention it in the docs?
For us it doesn't really matter. We will handle that inside Javis then.

[cormullion]

Looking at 2.4:

function image_as_matrix()
    if length(CURRENTDRAWING) != 1
        error("no current drawing")
    end
    w = Int(current_surface().width)
    h = Int(current_surface().height)
    imagesurface = CairoImageSurface(fill(ARGB32(1, 1, 1, 0), w, h))
    cr = Cairo.CairoContext(imagesurface)
    Cairo.set_source_surface(cr, current_surface(), 0, 0)
    Cairo.paint(cr)
    data = imagesurface.data
    Cairo.finish(imagesurface)
    Cairo.destroy(imagesurface)
    return reinterpret(ARGB32, permutedims(data, (2, 1)))
end

and 2.5

function image_as_matrix()
    if length(CURRENTDRAWING) != 1
        error("no current drawing")
    end
    w = Int(current_surface().width)
    h = Int(current_surface().height)
    z = zeros(UInt32, w, h)
    # create a new image surface to receive the data from the current drawing
    imagesurface = CairoImageSurface(z, Cairo.FORMAT_ARGB32)
    cr = Cairo.CairoContext(imagesurface)
    Cairo.set_source_surface(cr, current_surface(), 0, 0)
    Cairo.paint(cr)
    data = imagesurface.data
    Cairo.finish(imagesurface)
    Cairo.destroy(imagesurface)
    return reinterpret(ARGB32, permutedims(data, (2, 1)))
end

they kind of look the same... - perhaps you were using a intermediate master?

[Wikunia]

So we used v2.4 up to now and GitHub Actions used v2.5 for the last one which broke: https://github.com/Wikunia/Javis.jl/runs/1082538562 with this PR setting the upper bound to only include v2.4 it worked again.
Therefore we expected that you made some breaking change.

[Wikunia]

But yeah you make a good point. Can I help in anyway to figure out what happened?

[cormullion]

Yes, please! I don't know where the problem is in Luxor, because the two releases look to be the same, and the transposition was only present in one or two master versions while I was developing the alternative approach.

Luxor 2.4

julia> m = @imagematrix begin
             background("red")
             end 10 1
10×1 reinterpret(ColorTypes.ARGB32, ::Array{UInt32,2}):
 ARGB32(1.0N0f8,0.0N0f8,0.0N0f8,1.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)

Luxor 2.5

julia> m = @imagematrix begin
             background("red")
             end 10 1
10×1 reinterpret(ColorTypes.ARGB32, ::Array{UInt32,2}):
 ARGB32(1.0N0f8,0.0N0f8,0.0N0f8,1.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)
 ARGB32(0.0N0f8,0.0N0f8,0.0N0f8,0.0N0f8)

(Also, both answers are still wrong, so I still have to look into this some time... :( )

[Wikunia]

I have the following code:

using Luxor, Images

Drawing(10, 2, :image)
origin()
img = image_as_matrix()
finish()
println(size(img))
img = convert.(RGB, img)
save("luxor_test.png", img)

on Luxor 2.4 it prints (2, 10) and the image is:

on Luxor 2.5 it prints (10, 2) and the image is:

[cormullion]

What dark sorcery is this?! :)

[Wikunia]

Oh BTW I use a dark theme so the first version actually is white 😂
Also I don't know why the one is white and the other is black. Isn't the default white? Or is it transparent?
Can you reproduce this with the code on your system @cormullion ? I use linux btw

[cormullion]

Yes

2.4:

 2×10 reinterpret(ARGB32, ::Array{ARGB32,2}):

2.5

10×2 reinterpret(ARGB32, ::Array{UInt32,2}):

and yes there's an open issue about why this doesn't work well... :)

[cormullion]

On 2.4:

w = Int(current_surface().width)
h = Int(current_surface().height)
imagesurface = CairoImageSurface(fill(ARGB32(1, 1, 1, 0), w, h))

On 2.5:

w = Int(current_surface().width)
h = Int(current_surface().height)
z = zeros(UInt32, w, h)
imagesurface = CairoImageSurface(z, Cairo.FORMAT_ARGB32)

I thought I was making the initialization slightly faster - but perhaps this is flipping the dimensions somehow?

[Wikunia]

Oh yes it does:
v2.5 gives:

Cairo.CairoSurfaceImage{UInt32}(Ptr{Nothing} @0x00000000050b2eb0, 50.0, 100.0, UInt32[0x00000000 0x00000000 … 0x00000000 0x00000000; 0x00000000 0x00000000 … 0x00000000 0x00000000; … ; 0x00000000 0x00000000 … 0x00000000 0x00000000; 0x00000000 0x00000000 … 0x00000000 0x00000000])

and v2.4 gives:

Cairo.CairoSurfaceImage{ARGB32}(Ptr{Nothing} @0x000000000402a540, 100.0, 50.0, ARGB32[ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) … ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8); ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) … ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8); … ; ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) … ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8); ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) … ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8) ARGB32(1.0N0f8,1.0N0f8,1.0N0f8,0.0N0f8)])

So the 100 and 50 are swapped.

I used

julia> w = 100
100

julia> h = 50
50

[cormullion]

Ha, it won't be the first or last time I get my rows and columns mixed up... :)

I'll put that 2.4 init code back in and go for a 2.5.1.

[Wikunia]

It seems odd to me though. fill does the same as zeros, right? So it is something inside Cairo that mixes this up?

[Wikunia]

Oh you can do CairoImageSurface(z, Cairo.FORMAT_ARGB32; flipxy=true)

[cormullion]

now why would they put that keyword argument in?

[cormullion]

JuliaGraphics/Cairo.jl#252 perhaps

[cormullion]

no, JuliaGraphics/Cairo.jl#68 looks like the early days of Julia...

[Wikunia]

Wait it must be CairoImageSurface(z, Cairo.FORMAT_ARGB32; flipxy=false) then. Sry

[cormullion]

That's a terrible name anyway.... "I'm always getting A and B the wrong way round, so let's add an option called FLIPAB!"

[Wikunia]

That's how it works, right? You just transpose and rotate and flip it often enough until it works and call it a feature that you can do that easily 😂

[cormullion]

Hopefully fixed in 2.5.1.