Feat: Extend platform abstraction

[wouterlucas]

Move Image creation and GL wrapper to Platform.

This PR changes:

• createImageBitmap support to Platform
• Image fetch to Platform (by default using XMLHttpRequest)
• ImageWorker handling to Platform
• GLWrapper to Platform
• Similar, support for TX compression and SVG handling has been moved to Platform

Removed:

• createImageBitmap auto detection - this needs to be done by Platform
• Image Fallback handling - this is done by Platform

NOTE: BREAKING CHANGES
This requires a different Platform import / init to make it work.

The concept is you create a Platform that matches the functionality the platform exposes. I.e. if the Platform does not support createImageBitmap or a less version of createImageBitmap you should extend the platform to match that.

@estobbart for ION you can create or upstream an ION specific platform (or we can create one) that:

• Replace loadImage and createImage in Platform (possibly Fetch too?)
• Replace the respective GL function

Todo:

• Expose platforms in exports
• Create Legacy Platform for non-createImageBitmap platform
• Create Chrome 50 createImageBitmap platform
• Create fetch supported platform

[estobbart]

Couple of questions..
L2 had a force draw capability so that every raf would draw, is that possible here?

[estobbart]

this bit was confusing.. when should it ask canvas for a context vs the platform layer?

[wouterlucas]

this is just to force the context to webgl2 if that's supported based on config - that is added for when devices support both but we want to force it

[estobbart]

why not get the canvas from the platform?

[estobbart]

not sure I understand the intent w/ wrapping fetch here

[wouterlucas]

added that because not all devices support fetch API and require some specifics around using XMLHttpRequest - some older Smart TVs give us trouble with local URLs or other specifics, to allow Platform layers to modify the requests if needed,

[estobbart]

worth a check first?

[estobbart]

IMO loadend would be better

[wouterlucas]

can look into that - but as said some devices are really picky about this, especially older Samsung devices

[estobbart]

maybe canvas should be one of the platform settings (along with force & num workers).. then the platform knows if it needs to create a canvas or not. Then platform createCanvas could be getCanvas.. making it more clear if it should be creating, and/or what the ownership is supposed to be of the canvas.

[wouterlucas]

yeah struggling with that a little bit, there are multiple Canvas being used in certain cases:

• Main drawing canvas
• Font generation canvas
• SVG canvas (if used)

So I initially just had platform set itself, but then got stuck with a 1x1px Canvas used for fonts with clipping calculations.

Its not just the platform, its also the font engine that determines whether it is 1 or more Canvas'es used. This was easier, but open to improve it!

[estobbart]

having the property and the method is the confusing piece to me.. overall be good to understand the canvas usage/lifecycle that you described above.
my recommendation would be:

    const platform = new (settings.platform as any)({
      numImageWorkers: settings.numImageWorkers,
      forceWebGL2: settings.forceWebGL2,
      canvas: settings.canvas
    });

    // platform layer responsible for providing the canvas from settings or making one if not provided.
    this.canvas = platform.getCanvas();