DRAFT: enable MSAA with WebGLMultisampledRenderTarget without EffectComposer

[aardgoose]

Enables the WebGLMultisampledRenderTarget to target the default framebuffer for the blitFramebuffer operations, removing the need for EffectComposer and the extra copy pass.

example modified to test.

[Mugen87]

example modified to test.

The example should demonstrate MSAA in context of postprocessing which is the most relevant use case for WebGLMultisampledRenderTarget.

FYI: If it's a draft PR, then please use the respective github feature:

https://github.blog/2019-02-14-introducing-draft-pull-requests/

What is your case for this change?

[aardgoose]

I wasn't aware of the draft feature - rather well hidden.

The point was to allow MSAA without the overhead/complications of the postprocessing framework.

[mrdoob]

Oh, why was this closed?

[arpu]

@aardgoose i am interessierend in this too could you rebase this PR and reopen? or should i open a new one?

[arpu]

@Mugen87 i tested this patch against r127dev and get
GL_INVALID_OPERATION: Blit feedback loop: the read and draw framebuffers are the same.
would be cool if you could look at this if you have time.

[Mugen87]

This change does not work 1:1 when applied to latest dev since framebuffer management has changed.

I'm also not sure if the directToCanvas property is a good solution...

[arpu]

for me the most imported part is setting the Hardware MSAA, because Chrome set it to 4x as default still if gl.MAX_SAMPLES is higher ( 8x,16x)

https://bugs.chromium.org/p/chromium/issues/detail?id=1063437

[arpu]

@Mugen87 maybe i oversee something? is there any other simpler way to set this?

[Mugen87]

GL_INVALID_OPERATION: Blit feedback loop: the read and draw framebuffers are the same.

@arpu This warning should be gone after #21570.