> then each CopyRect is one dynamic buffer update PS: *two* buffer updates, so even worse ;)
On Tuesday, 25 February 2020 14:16:31 UTC+1, Floh wrote: > > PS: if I'm seeing it right, than SDL2 is using GLES2/WebGL under the hood, > and an SDL_CopyRect() might be this under the hood: > > > https://github.com/emscripten-ports/SDL2/blob/ca38e297ce62322ea9bcde2ab78afab6aa93f423/src/render/opengles2/SDL_render_gles2.c#L1820-L1858 > > ...and if this is true, then each CopyRect is one dynamic buffer update > (vla glBufferData() or glBufferSubData()) and a draw call, and that's for > each rectangle (so it looks like no batching happens at all). > > This sort of stuff is very fast in native GL implementations, and very > slow in WebGL (e.g. it's even more expensive than the 'trivial draw call' > example in my post above. IME this explains the performance difference you > are seeing, and also why the software renderer is faster, the WebGL calling > overhead is much more expensive than the actual drawing operations. > > The way to make this scenario fast in WebGL is via "sprite batching": have > two big vertex buffers (alternating each frame, one 'in flight' for > rendering, the other currently filled with the CPU), write all the > rectangle vertices for one frame into a memory chunk, do a single > glBufferSubData() to copy into a GL vertex buffer, followed by a single > glDrawArrays(). Ideally use a single texture atlas which has the images for > all used sprites, or if that's not possible, have very few atlasses, and > sort sprites within a "depth layer" by texture. E.g. do everything to > minimize the number of draw calls as much as possible. > > On Tuesday, 25 February 2020 14:02:06 UTC+1, Floh wrote: >> >> I don't know how the 2D operations in the emscripten SDL shim are >> implemented versus 'native SDL', but I would actually expect massively >> different performance behaviour, since I'm seeing the same for WebGL vs >> native OpenGL, and the same might be true for HTML canvas vs whatever SDL >> is doing in the native implementing (assuming the 2D operations of the >> emscripten SDL "emulation" go through HTML canvas). >> >> To give you an idea of how bad it is on WebGL vs GL: the "number of >> trivial drawcalls (16 byte uniform update plus glDrawArrays()) before >> dropping below 60fps" on WebGL in desktop browsers is around 5000, in a >> good native GL implementation (like NVIDIA on Windows), that number is >> about half a million (although the number varies there extremely too, e.g. >> Intel GPUs in common laptops only manage around 15k). >> >> I would expect similar differences for your situation. >> >> So basically: just compiling the code usually isn't enough, the code must >> also be changed for the specific performance characteristics of the web >> platform (e.g. for WebGL vs GL this means that "old school" batching tricks >> must be used to reduce the number of calls into the GL API as much as >> possible). >> >> Cheers, >> -Floh. >> >> On Monday, 24 February 2020 23:05:23 UTC+1, Rob Probin wrote: >>> >>> I've been using Emscripten with SDL2 to do some 2D game work. I wrote a >>> test program (concerned that my code was problematic) .. it turns out it >>> gives some weird results... like software renderers are faster than >>> hardware renderers, and that with accelerated SDL_FillRect and SDL_CopyRect >>> are about 120x faster on a native build than a web build.... >>> >>> Old build uploaded for your excitement (instant results!) >>> http://robprobin.com/SDL2_emscripten_tests/ >>> >>> Test code: >>> https://github.com/robzed/SDL2_emscripten_tests >>> >>> Some results here: >>> https://discourse.libsdl.org/t/emscripten-sdl2-performance/27236/ >>> >>> Comments or thoughts welcome. >>> >>> Yeah, less sprites or rects would make it work better :-) >>> >>> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/0f9ef5be-003f-469d-a257-644a9901f396%40googlegroups.com.
