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 5236 - Huge FPS drop in SDL2 compared to SDL1
Summary: Huge FPS drop in SDL2 compared to SDL1
Status: RESPONDED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-17 17:57 UTC by hubert.vansteenhuyse
Modified: 2020-07-24 04:17 UTC (History)
1 user (show)

See Also:


Attachments
Screenshots FPS SDL 1 above, SDL 2 below (361.48 KB, image/jpeg)
2020-07-17 17:57 UTC, hubert.vansteenhuyse
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hubert.vansteenhuyse 2020-07-17 17:57:41 UTC
Created attachment 4419 [details]
Screenshots FPS SDL 1 above, SDL 2 below

Hello,

I have a 43% performance loss in my game when I switch from SDL 1.2.15 to SDL 2.0.4 or SDL 2.0.8.
I have this on Linux and Windows on different hardwares.
I compared my SDL2 code with existing open source games and I can't find anything wrong.

As you can see in the attachment the SDL1 FPS = 146 and for SDL2 = 84 using OpenGL to render 1300 triangles.
Apart from the SDL calls, everything else is identical.

This performance loss happens when SDL_GL_SwapBuffers/SDL_GL_SwapWindow is called.
Some SDL_GL_SwapBuffers time measurements: 0.007, 0.007, 0.007, 0.008, 0.006, 0.008, 0.007, 0.008, 0.005, 0.008, 0.006, 0.008, ...
Some SDL_GL_SwapWindow  time measurements: 0.020, 0.012, 0.054, 0.000, 0.008, 0.008, 0.011, 0.017, 0.010, 0.008, 0.013, 0.020, ...
The SDL_GL_SwapWindow line also shows stuttering.
This looks like a swap/vsync problem but both versions run on the same identical environment.

Changing driver options like swap interval, different SDL_GL_CONTEXT_PROFILE_MASK and versions, SDL_GL_SetSwapInterval, etc. ... do not help.
Proposed solutions on popular forums do not help either.


Why is SDL2 so much slower than SDL1?
Are there known issues or workarounds for this?

This performance loss is so frustrating especially when so much time and effort is put in optimizing engine and game algorithms.


Thank you for your time!
Hubert.
Comment 1 Ryan C. Gordon 2020-07-17 20:46:03 UTC
There are a million little reasons this could be different, as the GL context creation code is completely different between 1.2 and 2.0.

It might be worth trying to disable X11 compositing before launching your program:

export SDL_VIDEO_X11_NET_WM_BYPASS_COMPOSITOR=1


...also, are you running in a window or fullscreen?

First things first, though: SDL 2.0.8 is over two years old (2.0.4 is over four), so I would definitely try a newer version in any case.

--ryan.
Comment 2 hubert.vansteenhuyse 2020-07-17 21:34:34 UTC
A million little reasons, ok, but 43% is huge.

The FPS drop is there too in windowed mode, it is less obvious but that is only because the FPS is so much higher than in full screen mode.

The export didn't work unfortunately.

I had it on a more recent version on Windows but I don't recall the version, but it is not the latest version, that I know.

Ty Ryan.
Comment 3 hubert.vansteenhuyse 2020-07-24 04:17:59 UTC
Meanwhile I know why this is all happening at least in X11.

The XSetWindowAttributes::backing_store member is not useful for 3D rendering applications.
It can conflict with or interfere during the swap of the rendering buffers of the 3D api.

Also, for a full screen window the XSetWindowAttributes::override_redirect member is set to False.
You probably changed this to have a better behavior between a full screen window and desktop environments (gnome, kde, xfce, ...).
This slows the thing really down, some desktop environments probably interact with something, go figure... .

All of that when the disabling of the vertical screen synchronization was successful.
The gl context is fine.