The behaviour of runApp with wrong sized canvas is strange

[kfl]

If the draw argument for runApp returns a canvas that's to small or to big wrt the given arguments, the result is strange.

For instance, the following program:

#r "nuget:DIKU.Canvas, 1.0.0"

let bug =
    Canvas.runApp "Opps" 42 69
                  (fun _ _ _ -> Canvas.create 420 4220) (fun _ _ -> None) ()

Will give an System.ArgumentException: Destination array was not long enough error.

Likewise, the following program:

#r "nuget:DIKU.Canvas, 1.0.0"

let bug =
    let apple = Canvas.fromFile "apple.jpg"
    Canvas.runApp "Oh no" (Canvas.height apple) (Canvas.width apple) // width and height is swapped
                  (fun _ _ _ -> apple) (fun _ _ -> None) ()

Where the width and height arguments to runApp are swapped, results in garbled output.

[Xatha]

Hi @kfl!

I believe the first instance happens when you try to buffer a frame (canvas), from the draw function, that is larger than the given height h and width w in runApp. The program will crash because our buffer's size is calculated from w, h and not the actual frame's size. Although, this usually does not matter since the frame from draw is usually the same size as w, h. But nothing stops us from creating a draw function that will return a Canvas with a larger (or smaller) size than w, h .

Your example demonstrates this point well. You parse (fun _ _ _ -> Canvas.create 420 4220) to runApp as your draw function. But no matter what w, h is parsed into your expression, you return a Canvas with the dimensions of 420x4220. This is a lot more bytes than the size of the buffer which is initialised for frames of only 42x69. Our buffer is too small to store the data from our frame.

I believe the second instance occurs because swapping the height and width will mess with the pitch calculations for SDL.SDL_UpdateTexture(). Again, this is because we are not basing our calculations on the frames given, but on the given canvas window size.

A possible solution will be to calculate our buffer size from the first frame from draw. Although, this can still theoretically break if draw returns frames that become increasingly larger. Although, I do not believe that would be a correct use of draw.

I attempted to fix this issue, and I created a PR with my proposed solution.

[kfl]

No longer relevant in version 2.0