Pixi.js: [RFC] Remove failIfMajorPerformanceCaveat for pixi v5

[teoxoy]

Currently isWebGLSupported uses failIfMajorPerformanceCaveat.

https://github.com/pixijs/pixi.js/blob/824b8d20ecbacad0c80d82a002009aded7f62ab1/packages/utils/src/browser/isWebGLSupported.js#L16

This is one of the few blog posts that I found to talk about failIfMajorPerformanceCaveat and it recommends that failIfMajorPerformanceCaveat is used when you have a fallback.

Having isWebGLSupported fail if major performance caveat is true was fine for v4 but I propose that we remove the option for v5 as canvas is not supported by pixi v5 anymore meaning there is no fallback anymore.

This might seem like an insignificant thing but I already got 2 reports about the app not working since I switched to v5 and I narrowed down the issue to this option used by isWebGLSupported.

I can put up a PR for this if the response is positive.
Let me know what you think!

[ivanpopelyshev]

Its supported in pixi.js-legacy package. Fallback is still here and I'm working on improving it. It was moved away from main package just because of current trends in JS community: smaller builds.

[themoonrat]

If we remove it, then the next reports you will be getting will be about really awful performance, as opposed to it not working. Which still isn't satisfactory. As ivan says, I'd recommend using the legacy package. I wonder if we could move the failIfMajorPerformanceCaveat option to the settings to at least allow developers to go down that rabbit hole if they wish to?

[teoxoy]

I think I misunderstood something. I thought that v5 has only WebGL support and that the pixi.js-legacy package is just pixi v4.

I think a setting to turn failIfMajorPerformanceCaveat on and off would be the best way to go about this. Some apps might not even be impacted as much by the preformace hit. failIfMajorPerformanceCaveat is implemented differently for each browser and might test for things unrelated to the needs of an app.

Should I start a PR for this?

[ivanpopelyshev]

I think I misunderstood something. I thought that v5 has only WebGL support and that the pixi.js-legacy package is just pixi v4.

Well, we thought that canvas should be deprecated , but reality knocked in our door ;)

Some apps might not even be impacted as much by the preformace hit.

Agree. Btw, in that case they need some other adjustments, like turning off multitexture rendering, ...

[teoxoy]

Well, we thought that canvas should be deprecated , but reality knocked in our door ;)

:))

Agree. Btw, in that case they need some other adjustments, like turning off multitexture rendering, ...

Why? Doesn't multitexture rendering work in an environment where failIfMajorPerformanceCaveat would fail?

[stevenalanstark]

5778 relates to this as well

[englercj]

We should allow users to specify their preference for this value, defaulting to being enabled. Users should be able to make a choice here, but for most pixi use-cases true is the value you want, and you should handle the failure.

Generally speaking for real-time applications you do want to fail in these cases, because the alternative is your application not really working anyway. Ideally, you detect a WebGL failure and inform the user their graphics hardware is not supported. Whether that failure was because of failIfMajorPerformanceCaveat, blacklisted drivers, lack of stencil buffer support, or any other reason is not really important. No matter the reason you need to inform them their GPU/Browser needs to be updated.

That being said, for non-realitime applications (chart rendering lib, rendering a single frame, etc) you are probably OK with it using software rendering as performance is not as large of a concern and users should be able to make that choice for their app.

[teoxoy]

The new setting looks great!
Thanks for implementing it!

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.