Generalize the signature of CairoImageSurface constructor

[GunnarFarneback]

In GtkReactive there's a call to Cairo that for Julia 0.6 was

Cairo.CairoImageSurface(reinterpret(UInt32, img), Cairo.FORMAT_RGB24)

With the lazy reinterpret in Julia 0.7 this can no longer be used directly and it's necessary to force it to materialize the reinterpret before sending it over:

Cairo.CairoImageSurface(Matrix(reinterpret(UInt32, img)), Cairo.FORMAT_RGB24)

However, in the default case that the image needs to be transposed, this unnecessarily makes two copies of the data instead of one, since permutedims could work directly on the ReinterpretArray if the constructor accepted it.

Cc: @timholy

[lobingera]

Could you provide more info on the "in the default case that the image needs to be transposed"? And where this is/should be done? This might be a case, where you keep the data as it is and use coordinate transformation to get the transpose (rotation).

[GunnarFarneback]

Line 263 of Cairo.jl:

function CairoImageSurface(img::Array{UInt32,2}, format::Integer; flipxy::Bool = true)
    if flipxy
        img = permutedims(img, (2,1))
    end
    ...
end

Unless you opt out of flipxy, the image is transposed first thing.

[GunnarFarneback]

Not sure about the best way to implement it. Maybe an additional method

function CairoImageSurface(img::AbstractArray{UInt32,2}, format::Integer; flipxy::Bool = true)
    if flipxy
        img = permutedims(img, (2,1))
    end
    if typeof(img) != Array{UInt32, 2}
        img = Matrix(img)
    end
    return CairoImageSurface(img, format, flipxy = false)
end

would be a solution. Probably want to avoid the glaring type instabilities (of img) though. But this originates from @timholy, so maybe he has better ideas.

[timholy]

Best would probably be a method specifically for ReinterpretArray; I think one could then do the transposing & reinterpretation simultaneously, given that this works:

julia> x = RGB24(0.2, 0.8, 0.5)
RGB24(0.2N0f8,0.8N0f8,0.502N0f8)

julia> reinterpret(UInt32, x)
0x0033cc80

[donm]

I just wanted add that the corollary of flipxy causing allocation is that it prevents seeing mutations of the data from being applied to the img argument. That's obvious, of course, but I could image one or two ways of implementing changes recommended in this issue (and from this Discourse thread), so for the sake of choosing between different designs I wanted to point out that use case for the function.

Also, should the methods for RGB24 and ARGB32 types also have a flipxy argument? Since that argument defaults to true, it seems like their current behavior is different than the behavior of the UInt32 method.

In case it's helpful, the context that led me here was drawing onto a CairoImageSurface in Compose.jl as a way of performing the drawing instead of writing a PNG to a file or IOBuffer.