This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Test VC2015 solution demonstrating the observed performance (BunnyMarkSDL.zip, application/x-zip-compressed, 2016-02-03 23:04:19 +0000, 27581 bytes)
• CPU profile screenshot (2016-01-20.png, image/png, 2016-02-03 23:13:36 +0000, 23996 bytes)

Reported in version: 2.0.4
Reported for operating system, platform: Other, ARM

Comments on the original bug report:

On 2016-02-03 23:04:19 +0000, John Girvin wrote:

Created attachment 2374
Test VC2015 solution demonstrating the observed performance

A Lumia 520 patched to the latest version of Windows Phone 8.1 can animate approximately 100-150 32x32 pixel alpha blended sprites rendered via SDL_RenderCopy before 60fps cannot be maintained. This is out of line both with the expected performance of the device and with the performance of other rendering implementations on the same device. For example, Cocos2D-X 3.9 can render 2200 such sprites at 60fps.

Confirmed this is observed via the D3D11 render path.

On 2016-02-03 23:09:06 +0000, John Girvin wrote:

The device seems to be CPU bound. SDL_RenderCopy (mostly D3D11_RenderCopy) accounts for 85% of theCPU time: 60% in D3D11_UpdateVertexBuffer "external code", 25% in "external code" in other parts of D3D11_RenderCopy.

A Lumia 1320 can animate ~300 sprites with the same code with approximately 1.7x the CPU power of the Lumia 520 (1.7Ghz core vs. 1.0Ghz), which would appear to be in line with the render path being CPU bound.

On 2016-02-03 23:13:36 +0000, John Girvin wrote:

Created attachment 2375
CPU profile screenshot

On 2016-06-12 21:30:25 +0000, David Ludwig wrote:

John, by chance, have you done any performance testing of SDL's renderer API on non-UWP platforms?

I'm wondering if SDL's renderer API may be inherently CPU-bound, regardless of which API backend (D3D11, OpenGL, etc.) gets used, due to its design.

On 2016-06-12 21:35:33 +0000, David Ludwig wrote:

To note, I get roughly the same performance when using the OpenGLES 2 render on my own Lumia 520 (enabled via use of the ANGLE for WinRT/UWP library, available on nuget.org).

On 2016-06-12 21:45:52 +0000, David Ludwig wrote:

... to add: I am able to render 100 bunnies at 60 fps on a Lumia 520, running WinPhone 8.1, in both the D3D11 and OpenGLES 2 renderers. With 300 bunnies, both render at approximately 33 FPS, give or take a few FPS.

I tried upping the D3D11 render's buffer-count from two, to three, but that didn't appear to give any significant change in performance. My testing was limited to a few runs, though.

On 2016-06-13 07:04:07 +0000, John Girvin wrote:

The Lumia 520 tests I ran were built from a standard DirectX/C++ Windows Phone 8.1 project template (the attached VS2015 solution), not a Windows 8.1 Universal project. Does that help?

FWIW I also did a version using SDL_gpu and got 700 bunnies on the same handset.

On 2018-08-06 21:20:19 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.