[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Context creation flag proposal: "failIfMajorPerformanceCaveat"



Very interested in this, and I think it's a slightly better proposal than has been made before. The statement that removes the subjectiveness of the flag and makes it something implementable (in my mind) is "if WebGL is known to be drastically slower than a native app making equivalent OpenGL calls". Browser vendors still have to decide when to apply it but there is at least a good litmus test: is a major source of overhead unique to WebGL running in this specific browser/OS/etc and not present in normal GL on the same exact hardware/OS?


On Mon, Sep 16, 2013 at 6:42 PM, Kenneth Russell <kbr@google.com> wrote:

As much as I wish that such a flag wasn't necessary, it's been found
to be needed in certain situations by a major consumer of WebGL
(Google Maps) and for this reason I support adding it to the spec.

failIfMajorPerformanceCaveat sounds reasonable given that it should
cover a range of scenarios. The text describing it will have to be
non-normative, but hopefully browsers will honor the flag in
situations known to have less than ideal performance. Reading back the
frame buffer in order to composite it with the rest of the page, no
matter the type of GPU, qualifies as such a situation in my opinion.

-Ken



On Mon, Sep 16, 2013 at 4:45 PM, James Darpinian <jdarpinian@google.com> wrote:
> I'd like to propose a new context creation flag to help WebGL apps make
> better decisions about performance tradeoffs:
> "failIfMajorPerformanceCaveat".
>
> The problem:
>
> The problem we're facing is that WebGL sometimes offers drastically reduced
> performance compared to what you would expect given the hardware it's
> running on. For example, if a machine has a GPU that is blacklisted for
> WebGL, the browser might use a software renderer that is much slower. Or, if
> the browser is using a software compositor, it might have to readback the
> WebGL framebuffer into system memory before drawing it to the screen.
>
> For apps that aren't full-screen or otherwise don't stress performance too
> much, these reduced-performance modes can work fine, so we don't want to
> simply disable WebGL in these cases. However, many apps don't work well in
> these reduced-performance modes. Apps that have a fallback rendering path
> (e.g. a 2D canvas mode) might prefer to use it instead of a
> reduced-performance WebGL context, but right now there's no way for apps to
> tell when WebGL is in a reduced-performance mode (vs. the user's machine
> just generally being slow).
>
> The proposal:
>
> "failIfMajorPerformanceCaveat" would default to false. When
> "failIfMajorPerformanceCaveat" is true, context creation would fail if WebGL
> is known to be drastically slower than a native app making equivalent OpenGL
> calls.
>
> This means, for example, that context creation would fail if the browser has
> to readback the WebGL framebuffer into system memory before drawing it to
> the screen. Context creation would also fail if the browser is using a
> software renderer due to the user's GPU being blacklisted for WebGL. In
> these cases apps could switch to a fallback rendering path, or try again
> with "failIfMajorPerformanceCaveat:false" and the knowledge that they should
> use a low-resolution mode.
>
> Thoughts? Alternate naming suggestions?

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------