Wasm-bindgen: Add 2D canvas support to web-sys

Created on 10 Jul 2018  路  11Comments  路  Source: rustwasm/wasm-bindgen

This is a tracking issue for adding support for the canvas 2D API to the web-sys crate.

General info on canvas 2D: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API

How to add support for new Web APIs to web-sys: https://rustwasm.github.io/wasm-bindgen/web-sys/supporting-more-web-apis.html

Interfaces

Here is a list of interfaces we need to support:

  • [ ] HTMLCanvasElement
  • [ ] CanvasRenderingContext2D
  • [ ] CanvasGradient
  • [ ] CanvasPattern
  • [ ] ImageBitmap
  • [ ] ImageData
  • [ ] TextMetrics

Example

  • [ ] Add an example to examples/ that shows off working with canvas 2D
help wanted web-sys

All 11 comments

I鈥檇 like to pick this up! 馃槉

Is there a story for handling mutliple constructor functions? Right now doing a cargo build on CanvasRenderingContext2D.webidl errors with

the name `__wbindgen_describe___widl_f_new_Path2D` is defined multiple times

which makes sense based on the idl

https://github.com/teovoinea/wasm-bindgen/blob/729e67423b8a27f89b40de295fcaf1f93dbf1b50/crates/web-sys/webidls/enabled/CanvasRenderingContext2D.webidl#L392-L399

@teovoinea for now that I don't think is supported so it should be fine to comment out one or two of the constructors, but in the long run we'll want to probably add support to generate multiple differently named constructors for instances like that

What do you think, which names in Rust should be used for constructors/functions with same names, but different argument types? Should they be generated from types names? Or manually annotated somewhere?

The current thinking is that we'd do something programmatic like:

  • First constructor is named new
  • Second constructor with arg foo is named new_with_foo
  • Third constructor with arg foo and bar is named new_with_foo_and_bar
  • etc...

And at least see how far that gets us, although we're also ok commenting out the duplicate constructors for now!

The problem is that for WebSockets all 4 overloads of method send are useful, and they have same argument names:

  [Throws]
  void send(DOMString data);

  [Throws]
  void send(Blob data);

  [Throws]
  void send(ArrayBuffer data);

  [Throws]
  void send(ArrayBufferView data);

Aha yes! For that we may want to just special case/edit the WebIDL perhaps? Or maybe we can include the type name in the method name? (aka send_dom_string(data), etc)

Yes, and that is exactly what I am asking. Are current WebIDL entirely taken from somewhere else? Edits to them may make updating process harder. In case of generated names, it would probably require doing so in such way that every type has a distinct name (not sure if it will cause any problems).

The WebIDL is taken from Gecko's source tree I believe. There's no current consensus on how to solve this issue. Ideally it'll be handled in the webidl crate with the code it generates, and editing the WebIDL itself would be a last resort, yes.

I am currently working on a prototype of an implementation of automatically generated names.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

expobrain picture expobrain  路  4Comments

fitzgen picture fitzgen  路  3Comments

arilotter picture arilotter  路  3Comments

kyren picture kyren  路  3Comments

MarcAntoine-Arnaud picture MarcAntoine-Arnaud  路  3Comments