GraphicsDevice properties refactor

[mvaligursky]

This PR moves some properties which need to be public, as well as some shared code, from WebglGraphicsDevice back to GraphicsDevice. This is a follow up for #4009 and #4010.

API Changes - which are expected to have no impact to existing projects:

Following properties and functions are no longer exposed as public in GraphicsDevice class, as they have no use case:

updateBegin	
updateEnd	
clear	
copyRenderTarget
draw	

getBlending	
getDepthTest	
getDepthWrite	
getRenderTarget	
setBlendEquation	
setBlendEquationSeparate	
setBlendFunction	
setBlendFunctionSeparate	
setBlending	
setColorWrite	
setCullMode	
setDepthFunc	
setDepthTest	
setDepthWrite	
setIndexBuffer	
setRenderTarget	
setScissor	
setShader	
setStencilFunc	
setStencilFuncBack	
setStencilFuncFront	
setStencilOperation	
setStencilOperationBack	
setStencilOperationFront	
setStencilTest	
setVertexBuffer	
setViewport	

Additionally, VertexFormat.update has been deprecated, as well as VertexFormat.elements changed into readonly, as the engine does not support those being modified.

[slimbuck]

I'm wondering how this code gets executed (and also converted to es5).

This line is declaring a member and could also be initialising it, like canvas = null;. But the constructor does this.canvas = canvas;. So does the code on this line run after the constructor's call to super();, but before the rest of the constructor code?

[mvaligursky]

correct, when you step over this in the debugger, those things execute first (and will be set to undefined), before constructor.

[mvaligursky]

this is what it looks like in ES5

[slimbuck]

Interesting.

So could you do canvas = canvas; here, instead of doing it in the constructor?

In a class as large as this it probably makes little difference, but in general we don't want to be initialising members twice.

[mvaligursky]

I don't think so, you don't have constructor parameters available at that point in ES6 world. Only in ES5 it's transpiled to doing it all inside constructor.

[slimbuck]

So I guess in general we want to declare (and optionally initialise) variables here or in the constructor, but not both?

[mvaligursky]

I doubt that would make any perf difference .. but perhaps it'd be useful to test it in a class such as Vec3?

[willeastcott]

So yep, I probably wouldn't add that to Vec3. I considered it but so many are created, I decided to avoid potentially slowing the code down. But for classes that are rarely created, I think it's stylistically very nice (and actually maps directly to TypeScript).

[slimbuck]

I really don't like the idea instance members are initialised twice in our constructors, it's gross.

However reading here, they say private versions of these (which we hope to use in future) must be declared this way:

Note: Private fields can only be declared up-front in a field declaration.

So it seems we ultimately won't have a choice and hopefully compiler will optimise away the redundant set.