Missing support for images about elm-canvas

[joakin]

I'm in the middle of finishing the new version and still have some things to do, but it is something I want to look into.

From my investigations I think there is something doable the same way that elm-webgl does it, I'll have to see if we can do the same here.

I'll keep this open as reference for the feature 👍

[wadouk]

Any way to help ? I investigate to use it to reduce size of photo before upload.

[rtxanson]

I've been looking at it a bit too in this library, and ran into this same dilemma. It's one thing to implement drawImage, but it's another question about what to do with the image data and load process. Will look at elm-webgl though too

[joakin]

WebGL has now a Texture type with kernel code that does the loading, and then it is handled internally once you get the Texture opaque type back.

We can’t do that with Tasks or kernel code, so we have to find a different way to do the side effects to load the images. So while far from ideal, we need to work within Elm’s interop limitations.

There are two ways this could be done (that I can think of):

1. Use ports

Quite a boilerplatey solution because of the setup code but the most similar to using Task(s) to load textures/images.

• We would provide a helper in window.ElmCanvas to connect the ports in the app to handle request/loading/response boilerplate
• We would provide some decoders from Decode.Value to a Texture type in the Elm part of the library
• The user has to define ports in the Elm side, and connect them on the HTML side

Pros

• Most similar to the WebGL version
• keeps Texture loading independent of the Canvas.toHtml API and doesn’t mess with that part of the library

Cons

• Requires boilerplate wiring up in both the JS side and the Elm side, which is prone to errors and creates frustration on the developer if they can’t figure it out.

2. Use the HTML element for passing the textures in and getting events for when the Texture loaded or errored

This would be the least setup and a declarative solution, but it is using HTML elements and events to do the side effects, which can feel weird.

• We would add a new function toHtmlWith with an options record, where you would pass in a textureUrls: (List String) and also a onTextureLoad: Result err Texture -> msg
  • onTextureLoad will trigger once the image loads, for each URL passed

Pros

• Declarative and more direct to use. No ports setup or additional JS setup

Cons

• Adds the concern of image loading to the HTML element, where it seems like it should be a side effect better handled by Tasks, like in Elm WebGL. Sadly the same approach is not an option.

In any case:

• We would add a new namespace Canvas.Texture with functions to get information from a texture like the name and possibly the dimensions and other available information
• We would add some variation of the context.drawImage command that is more Elm like and as safe as possible, likely as a new type of renderable. I’ve been thinking about it and I think there are ways to be typesafe about the viewport of the image to render (to not draw out of bounds of the texture), we’ll see.
• We would add documentation for usage and examples of usage to make it as clear as possible.

—-

I’m still undecided about what would be the best option. I don’t particularly like option ports because it makes setup more complicated and that is already complicated enough having to instruct users to include the custom element JS. I have certain aversion to option 2, because it should be like in elm-WebGL but it can’t be, so this seems like the next best thing, but not optimal.

Both options as far as I can think about would be a minor version on the Elm side and option ports would be a major on the JS side and option toHtmlWith would be a minor in the JS side.

I would appreciate any thoughts or comments on the proposals and if there is any other way I’ve missed that this could be accomplished in a nice way.

Once there has been feedback I’ll work on a draft and get a taste of the API and post here when I have code samples.

[joakin]

I've coded up Option 2 and have it in a branch. I'm going to be looking into it to see how good of an API it is, I would appreciate your thoughts. In my opinion, it turned out quite well.

I'll point out here some links of things to look at:

• Example demo of loading a sprite sheet and drawing the images:
  • Demo: http://chimeces.com/elm-canvas/textures.html
  • Source: examples/Textures.elm
    • List the textures you want [1] and specify a Msg for each texture that loads [2]
    • Use Canvas.toHtmlWith to give the textures to load to the library [3]
    • When the texture loads or fails, react appropriately, storing the Texture in the model, and making sprites if you need to [4]
    • Use the texture function to get a Renderable that you can put in the screen, passing in a Texture [5] & [6]

In terms of the library, there is a new Canvas.Texture module that has functions to create and load textures, and to make windowed textures (sprites) out of already loaded textures. The docs right now in case you want to look at them: toHtmlWith, texture, and Canvas.Texture.*

As I said, I'd appreciate any feedback. You can clone the repo and go to the draw-image branch, and play with the examples, do make or make dist to build.

cc / @PixelPartner @wadouk @rtxanson @brainrape @brian-dawn @heracek

[brainrake]

Looks good! The api is fine, it's how you'd load an <img>.

[joakin]

Version 4 has been released, with more granular modules, and support for rendering images.

See the example: https://chimeces.com/elm-canvas/textures.html and the source: https://github.com/joakin/elm-canvas/blob/master/examples/Textures.elm

And the new docs https://package.elm-lang.org/packages/joakin/elm-canvas/latest/

I'm closing this for now, if other use cases come up regarding drawing images we can address them in new issues.