Combine createImageBitmap() / createPattern() / drawImage() checks

[annevk]

createPattern()/drawImage() have these checks:

1. If image is an HTMLOrSVGImageElement object whose current request's state is broken, then throw an "InvalidStateError" DOMException.
2. If image is an HTMLOrSVGImageElement object that is not fully decodable, or if image is an HTMLVideoElement object whose readyState attribute is either HAVE_NOTHING or HAVE_METADATA, then return bad.
3. If image is an HTMLOrSVGImageElement object with an intrinsic width or intrinsic height (or both) equal to zero, then return bad.
4. If image is an HTMLCanvasElement object with either a horizontal dimension or a vertical dimension equal to zero, then return bad.
5. If image is an ImageBitmap object with its [[Detached]] internal slot value set to true, then throw an "InvalidStateError" DOMException.

createImageBitmap() does not have 1, but always throws for 2 (which is a superset). 3 however is seemingly incompatible as createImageBitmap() only throws if sw/sh are not given. 4/5 are compatible.

@junov thoughts? Does the implementation look as messy as the specification setup? (And also, there are many checks that createImageBitmap() has that are not present in the other two methods. Is that intentional?)

[junov]

One of the differences is that createImageBitmap is async and drawImage is not. So with creatImageBitmap there is an opportunity to handle objects that are not yet loaded (meaning 2. could be revised). In the case of creatImageBitmap, it is conceivable that 3 may not be verifyable synchronously.

The implementation is not that messy because it uses a virtual interfaces through which each object type knows how to check whether it is in a usable state.

[annevk]

Well, createImageBitmap() does all these checks synchronously, well before it goes "in parallel". Arguably we could change it, but I'm mostly curious if we could get to a place that's closer to how implementations work, with shared checks.

[junov]

Right. I see two ways:

1. We could have a shared "check whether a CanvasImageSource is valid" algorithm.
2. A polymorphic design: We could state that all members of the CanvasImageSource union must have a [[getBitmap]] internal method, which returns a bitmap and may throw an exception if a bitmap could not be obtained.

I think 2) is more flexible. It it makes it easy to spec one-off behaviors if necessary:

if <var>image</var> is an XYZ:
        do something special
Otherwise:
         let <var>bitmap</var> be the result of calling <var>image</var>'s [[getBitmap]] internal method.

[annevk]

I ran a test with images/red-zerowidth.svg from web-platform-tests and it seems browsers throw anyway if the source image width (or height) is 0 so we can probably postpone 2 for now and just reuse the "usable" algorithm.