Re: [whatwg] Reviving ImageBitmap options: Intend to spec and implement

On Wed, Feb 10, 2016 at 10:25 AM, Domenic Denicola <> wrote:

> From: whatwg [] On Behalf Of Xida
> Chen
> > We intend to push this feature forward in Blink, particularly we intend
> to
> > spec and implement the "Strongly desired options" listed on the Whatwg
> > proposal page. We would appreciate comments and suggestions on the
> > proposal.
> >
> > Any thoughts or objections before we start drafting a change to the spec?
> Exciting stuff!

Agreed -- thanks Xida for pushing this feature forward. It'll significantly
improve texture handling performance in WebGL applications.

> > 'none': Do not change orientation.
> Does this mean "disregard image orientation metadata" or does it mean "do
> not change orientation from what the metadata specifies"?
> > enum colorspaceConversion, default = 'default'
> Is there any precedent on the web platform (or in Open GL APIs, perhaps?)
> for whether "colorspace" is one word or two words? If two words, this
> should be colorSpaceConversion. Happy to defer to your expertise here.

The WebGL spec has been using a single word for this, but two words are
probably more correct.

> > 'default': Implementation-specific behavior, possibly optimized for the
> implementation's graphics framework.
> This is a bit unfortunate as an interop hazard. I suppose it's no worse
> than today though. Has this been discussed in the past? Apologies, I was
> only able to skim the previous email thread.

This provides the functionality of the existing
images uploaded to WebGL are decoded "however the browser does it" -- which
isn't tightly specified -- but most WebGL apps that draw images just do
this and get correct results.

However, in special cases and for sophisticated apps, it's absolutely
necessary to get the raw data that's in the image, which is why there has
to be a switch to turn it off.


> ---
> This comment is on something outside the "strongly desired features"
> section so probably not relevant to your immediate work. Just wanted to
> mention it.
> > DOMString? crossOrigin
> In new JavaScript-only APIs we've made the decision to move away from the
> potentially-confusing HTML style crossOrigin enums in favor of the
> RequestCredentials enum used by Fetch:
> You can see this in
> e.g. where I chose the same
> initial crossOrigin design and Anne convinced me to move to credentials. I
> imagine we'll continue to use crossorigin="" and corresponding reflected
> crossOrigin IDL attributes for any HTML elements, but for JS-only APIs
> RequestCredentials is the way to go.

Received on Wednesday, 10 February 2016 18:53:45 UTC