[Webkit-unassigned] [Bug 228187] New: Very bad performance for dynamic vertex buffers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=228187

            Bug ID: 228187
           Summary: Very bad performance for dynamic vertex buffers
           Product: WebKit
           Version: Safari 14
          Hardware: iPhone / iPad
                OS: iOS 14
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: ANGLE
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: andrew.shaitorov at gmail.com
                CC: dino at apple.com, kbr at google.com, kkinnunen at apple.com

Hi!

We were preparing our html game for release and discovered a performance bug in iOS.

Our rendering technique to pretty common for the most 2D WebGL games: 

1) The game pushes all sprites quads each frame to a list for rendering;

2) After that we're doing some batching to reduce resulting draw calls in the list;

3) Then we upload all vertices and indices of quads using bufferData calls with GL_DYNAMIC_DRAW usage (just 2 calls per frame for vertex & index buffer);

4) Call glDrawElements for each batch to render the frame.

Then we start to profile the game on iOS using Safari and find out that drawElements consuming almost all CPU. After that we tried to replace drawElements call with drawArrays (by removing indices with duplicated vertices in the vertex list) and got a HUGE performance gain.

We have prepared a simple html reproducing the issue:

https://cinderella.sfo2.digitaloceanspaces.com/WebGLIndexedVsNonindexed.html

For iPhone 11 Pro Max iOS 14.6: FPS with indices: ~1.20, FPS without indices: ~60.0. So rendering with index dynamic buffer 40 TIMES slower than rendering without it!

For some Android devices we tested the difference is just about 20-30%.

We think that this bug affects a lot of 2D games and needs to be fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210722/5d929c9d/attachment-0001.htm>