We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3254 - SDL_RenderCopy slow on Windows Phone / D3D11
Summary: SDL_RenderCopy slow on Windows Phone / D3D11
Status: RESOLVED ABANDONED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: 2.0.4
Hardware: ARM Other
: P2 normal
Assignee: David Ludwig
QA Contact: David Ludwig
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-03 23:04 UTC by John Girvin
Modified: 2018-08-06 21:20 UTC (History)
2 users (show)

See Also:

Attachments
Test VC2015 solution demonstrating the observed performance (26.93 KB, application/x-zip-compressed)
2016-02-03 23:04 UTC, John Girvin 		Details
CPU profile screenshot (23.43 KB, image/png)
2016-02-03 23:13 UTC, John Girvin 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description John Girvin 2016-02-03 23:04:19 UTC 
Created attachment 2374 [details]
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.
Comment 1 John Girvin 2016-02-03 23:09:06 UTC 
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.
Comment 2 John Girvin 2016-02-03 23:13:36 UTC 
Created attachment 2375 [details]
CPU profile screenshot
Comment 3 David Ludwig 2016-06-12 21:30:25 UTC 
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.
Comment 4 David Ludwig 2016-06-12 21:35:33 UTC 
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).
Comment 5 David Ludwig 2016-06-12 21:45:52 UTC 
... 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.
Comment 6 John Girvin 2016-06-13 07:04:07 UTC 
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.
Comment 7 Ryan C. Gordon 2018-08-06 21:20:19 UTC 
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.