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

Re: [Public WebGL] WebGL Best Practices



Thank you for the elaborate messages, makes sense and useful to know.

Somewhat related to this, I've also been wondering about how Webassembly works with WebGL (and WebGPU). My assumption is that since WebGL is a web api, the wasm module has to "call out" to JS (using the import object) which is actually calling the WebGL API.
(So for example what emscripten does is it creates the wasm module, plus the import object which maps the OpenGL ES2 API calls to appropriate WebGL API calls implemented in JS?)
If this is the case, a purely JS application might even be faster to use WebGL than a wasm module as it has less overhead, comparing only the performance related to calling the API.
But is it, or is it going to be possible that a wasm module shortcuts this and executes WebGL commands more directly, at a lower level, avoiding some of the overhead present with calling it from JS and so actually be faster?

On Mon, May 25, 2020 at 9:19 PM Jeff Gilbert (jgilbert@mozilla.com) <public_webgl@khronos.org> wrote:

That's a great question! I would still consider that to be best practice.

In some browsers more than others, calling into the browser (C++) from
JS is relatively slow, whereas accessing a native JS cache is very
very fast.

Additionally, most browsers have (or are moving to) a split
content-process/gpu-process implementation of WebGL. In this case,
moving caching into the browser layer would be more difficult than the
caching a native JS app could choose to do, because the browser can't
assume, for example, that all validation succeeds before we update the
JS-accessible caches. It also means browsers need to maintain the
correct state in two places, instead of just in the
(privileged/trusted) gpu process.

In some cases, asking the browser for state reflection means a
round-trip between processes, which, on a busy machine, can be pretty
slow.

On Mon, May 25, 2020 at 9:09 AM Andrew Varga (grizzly33@gmail.com)
<public_webgl@khronos.org> wrote:
>
> That's a really useful page!
>
> I'm curious of something that is not mentioned here but I came across it many times, eg. in Chapter 9 - Optimizing WebGL Usage of "HTML5 Game Development Insights" and I think many engines follow this practice, which is basically to cache WebGL state in _javascript_ and only actually issue WebGL commands when needed:
> - keeping track of uniforms but only update them before a draw call, and only if their values have changed
> - cache all bindings (active texture unit, buffers, attributes)
> - cache blend states
> - ..etc, basically cache the entire WebGL state to reduce overhead
>
> Is this still consider a good practice? What I've been wondering is why this cannot be implemented by the browser, if this always makes sense to do?
> And is WebGPU going to be different in this regard?
>
> Thanks,
> Andrew
>
> On Fri, Mar 27, 2020 at 6:30 PM Ken Russell (kbr@google.com) <public_webgl@khronos.org> wrote:
>>
>> The investigation is underway in http://crbug.com/1065012 . The native implementation of requestPostAnimationFrame, which is behind the --enable-experimental-web-platform-features flag in Chrome, doesn't exhibit this problem.
>>
>> For the time being, the rPAF polyfill can be used in Firefox, and seems to carry some benefit there.
>>
>>
>>
>> On Fri, Mar 27, 2020 at 9:09 AM Ashley Gullen (ashley@scirra.com) <public_webgl@khronos.org> wrote:
>>>
>>> Why doesn't it work well in Chrome? rPAF seems to intuitively make sense once explained. Do you have a link to the discussion?
>>>
>>> On Thu, 26 Mar 2020 at 19:52, Ken Russell (kbr@google.com) <public_webgl@khronos.org> wrote:
>>>>
>>>> Note that there's an active ongoing discussion about the requestPostAnimationFrame best practice. It seems that the polyfill works well in Firefox, but not in Chrome. Suggest holding off adding that to your applications for the moment.
>>>>
>>>> -Ken
>>>>
>>>>
>>>> On Thu, Mar 26, 2020 at 11:40 AM Kai Ninomiya (kainino@google.com) <public_webgl@khronos.org> wrote:
>>>>>
>>>>> The MDN doc links to an explainer:
>>>>> https://github.com/WICG/requestPostAnimationFrame/blob/master/explainer.md
>>>>> It's pretty small, but it's also not a very complex feature (implementation-wise). As explained there, the original motivation was to allow querying computed DOM properties at a time when it's guaranteed it won't force a relayout.
>>>>>
>>>>> On Thu, Mar 26, 2020 at 5:05 AM Won Chun (won@cbrebuild.com) <public_webgl@khronos.org> wrote:
>>>>>>
>>>>>> Are there more resources about requestPostAnimationFrame? First I've heard of rPAF.
>>>>>>
>>>>>> -Won
>>>>>>
>>>>>> On Wed, Mar 25, 2020, 4:11 PM Ken Russell (kbr@google.com) <public_webgl@khronos.org> wrote:
>>>>>>>
>>>>>>> [cross-posted to webgl-dev-list]
>>>>>>>
>>>>>>> Dear WebGL community:
>>>>>>>
>>>>>>> Mozilla, with contributions from the rest of the WebGL working group, has just revised the WebGL Best Practices document. It contains a significant number of tips for best structuring WebGL applications and attaining top performance. Please check it out!
>>>>>>>
>>>>>>> On behalf of the WebGL working group,
>>>>>>>
>>>>>>> -Ken
>>>>>>>

-----------------------------------------------------------
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
-----------------------------------------------------------