3 ms·
> WebGL (and OpenGL) are awful APIs that can give you a very backwards impression about how to use them, and are very state-sensitive. It is not your fault for
by bowsamic 3y ago
> WebGL (and OpenGL) are awful APIs that can give you a very backwards impression about how to use them, and are very state-sensitive. It is not your fault for getting stuck here. Basically one of the first things everybody does is build a sane layer on top of OpenGL; if you are using gl.enable(gl.BLEND) in your core render loop, you have basically already failed.
I really don't understand this. Why the need for relentless abstraction? Just learn the ways that OpenGL is weird and use it anyway. Most people who work on these things will need to understand OpenGL anyway.
Then again, I guess it depends what you mean by "everybody" when you say "everybody does". Clearly, you are using hyperbolae here, but who do you actually mean by everybody? For example, if everybody did it then how did some people reach your failure case? Unclear and bizarre comment. If you say "everybody" you must at least attempt to clarify who is meant, else it is a contentless comment
- dwaite 3y ago(Based a bit on older OGL usage) > I really don't understand this. Why the need for relentless abstraction? Just learn the ways that OpenGL is weird and use it anyway. Most people who work on these things will need to understand OpenGL anyway. OpenGL/WebGL have a global state that affects drawing and which introduces side effects. Direct-written drawing code tends to make assumptions, which then makes it blow up when drawing code next to it makes different assumptions. The API abstraction means you don't really know how expensive it is to make state changes. So you tend to have either a thin abstraction that manages to set states appropriately for all your drawing code before use, flushing prior state, or you build a full local state manager that understands the 'delta' between old and new state.