Bug 220380 – [WinCairo] WebGL isn't shown in non-AC mode

• Component: WebGL
• Status: RESOLVED FIXED

[Fujii Hironori]

[WinCairo] WebGL isn't shown in non-AC mode

1. Start WinCairo MiniBrowser
2. Go to a WebGL page, for example, https://get.webgl.org/
   A cube is shown
3. Disable Accelerated Compositing.
   Menu → Debug → Use Accelerated Compositing
4. The cube disappears

[Fujii Hironori]

Created attachment 417114 [details]
WIP patch

[Fujii Hironori]

Created attachment 417116 [details]
Patch

[James Darpinian]

In this case, context creation should fail when the failIfMajorPerformanceCaveat context creation flag is set. Can you verify that is working?

[Kenneth Russell]

Comment on attachment 417116 [details]
Patch

r+ assuming jdarpinian's question is answered in the affirmative.

[Fujii Hironori]

(In reply to James Darpinian from comment #3)
> In this case, context creation should fail when the
> failIfMajorPerformanceCaveat context creation flag is set. Can you verify
> that is working?

No, it doesn't fail.
I don't think it should fail in the case.
Disabling accelerated compositing doesn't necessarily mean no GPU available.
I disables WinCairo's accelerated compositing for some purposes:

1. non-AC mode is still faster than AC mode in WinCairo. (WinCairo's compositor should be improved)
2. Comparing AC mode and non-AC mode rendering results for debugging compositor's issues

WebGL works nicely in non-AC mode with this patch. I think there is no MajorPerformanceCaveat.

[James Darpinian]

This exact situation, using glReadPixels in the compositing path, is exactly why failIfMajorPerformanceCaveat was originally added to the spec. It is a big performance problem for fullscreen WebGL apps on high resolution monitors.

[Fujii Hironori]

(In reply to James Darpinian from comment #6)
> This exact situation, using glReadPixels in the compositing path, is exactly
> why failIfMajorPerformanceCaveat was originally added to the spec. It is a
> big performance problem for fullscreen WebGL apps on high resolution
> monitors.

Yeah, it's pretty likely happening. Reading back from GPU to CPU is so expensive.

OK. I'm going to land the patch without solving the
failIfMajorPerformanceCaveat problem and leave the task into my
lengthy to-do list.

[Kenneth Russell]

(In reply to Fujii Hironori from comment #7)
> (In reply to James Darpinian from comment #6)
> > This exact situation, using glReadPixels in the compositing path, is exactly
> > why failIfMajorPerformanceCaveat was originally added to the spec. It is a
> > big performance problem for fullscreen WebGL apps on high resolution
> > monitors.
> 
> Yeah, it's pretty likely happening. Reading back from GPU to CPU is so
> expensive.
> 
> OK. I'm going to land the patch without solving the
> failIfMajorPerformanceCaveat problem and leave the task into my
> lengthy to-do list.

Would you mind filing a bug here under the WebGL component and blocking it on this one? That way at least it's tracked in a way that others might potentially contribute to the solution. Thanks!

[Fujii Hironori]

Sure.
Filed: Bug 220428 – [WinCairo] WebGL context creation should fail if accelerated compositing is disabled and the failIfMajorPerformanceCaveat context creation flag is set

[Fujii Hironori]

Comment on attachment 417116 [details]
Patch

Clearing flags on attachment: 417116

Committed r271254: <https://trac.webkit.org/changeset/271254>

[Fujii Hironori]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/72900500>