emscripten icon indicating copy to clipboard operation
emscripten copied to clipboard

Fix glDrawElements emulation

Open eukarpov opened this issue 1 year ago • 2 comments

This patch fixes an issue related to defining the buffer size before drawing. It introduces a slight overhead of O(N), however, it should not significantly impact performance. One option to prevent this overhead is to use glDrawRangeElements from OpenGL ES 3.0. However, the current glDrawRangeElements emulation reuses glDrawElements and should be rewritten.

eukarpov avatar Jul 31 '24 09:07 eukarpov

The per-draw-call temp JavaScript garbage that is generated in emulation code that counts the max index is worrying, as past experience shows that browsers will quickly deteriorate to microstuttering in animation in such cases. Ideally I think the code would avoid generating temp JS objects.

However since this is for relatively rarely used emulation path, that is fine to me either way. LGTM.

juj avatar Aug 01 '24 10:08 juj

Ideally I think the code would avoid generating temp JS objects.

Good point, +1 Let's avoid the object creation here.

kripken avatar Aug 01 '24 17:08 kripken

Ideally I think the code would avoid generating temp JS objects.

Good point, +1 Let's avoid the object creation here.

For now the code has been changed with array.reduce. Do you mean new arrayClass should be rewritten by using a loop and the buffer directly?

eukarpov avatar Aug 18 '24 11:08 eukarpov

By object creation, we mean the line with const arrayClasses = { .. }. That allocates a new object each time it is reached (maybe not each loop iteration if the JS VM is smart, but each call, at least). A sequence of ifs could avoid that, and should be fast enough here. If there were very many cases, another option would be to allocate an object once in the global scope, but I don't think we need that here.

kripken avatar Aug 22 '24 20:08 kripken

By object creation, we mean the line with const arrayClasses = { .. }. That allocates a new object each time it is reached (maybe not each loop iteration if the JS VM is smart, but each call, at least). A sequence of ifs could avoid that, and should be fast enough here. If there were very many cases, another option would be to allocate an object once in the global scope, but I don't think we need that here.

Thanks for the clarification. The type processing has been changed.

eukarpov avatar Aug 23 '24 16:08 eukarpov

Great! Thank you.

caiiiycuk avatar Aug 26 '24 21:08 caiiiycuk