Thank you for the detailed reply! On Tuesday, 25 February 2020 13:28:58 UTC, Floh wrote: > > > 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/74db47d3-ff09-46ef-855d-563cec222858%40googlegroups.com.
