Skip to content


[rbp] Enable Vsync as a default #2388

merged 1 commit into from

5 participants

Team Kodi member

I'll start this PR with the simplest fix, but it's more of an RFC.

Raspberry Pi currently defaults vsync to "let driver decide". This defaults to disabled.

For a low specced device, this is a bad default option.
Rendering more frames than you can display is pointless. Even f you do choose to use a 24/25/30 Hz mode, then the GUI still tries to update at 60+ fps and the cpu hits 100%.

I think a better fix would be to keep the default vsync as "let driver decide" (for Pi, and probably all platforms). And change the driver's default to enabled.

Would anyone object if this was the case for all platforms?
Is there any reason to run fps above vsync rate apart from benchmarking (which is still available with "always on"

Team Kodi member

With some hardware VSYNC causes eg. issues like high-cpu usage and such, so there is no "perfect" default :/

Team Kodi member

Could we make a list of what platform's don't want VSYNC?
It seems hard to imagine how limiting framerate to VSYNC can ever use more cpu.

I would like to claim that all GLES platforms do want VSYNC enabled. Any counter-examples?
If I said all GLES platforms want VSYNC enabled, any counter-examples?


uhm, how can it be hard to imaging vsync can every use more cpu?

the cpu is waiting for the retrace. on good drivers you get a callback from the gpu when the vsync occurs (or well, rather when the buffer switch occurs). on bad drivers you don't and have to poll. either you have it sleep, and miss a retrace (bad idea), or you have to spin. last mode eats cpu like babies.

Team Kodi member

Broken drivers. Seen it happen with Intel for example (in combination with older hardware)..

Team Kodi member

I would consider a graphics driver that busy waits for a vsync to be fundamentally broken.

Even so, if 1% of people are using such a driver, and they end up with high CPU after the change, which is fixed by changing the vsync option, and 99% of people get a an improved, lower CPU xbmc after the change, then it still sounds like a win.

I'm still going to claim that no GLES system suffers from this brokenness, and would benefit from enabling VSYNC. Any counter-examples?


is ok with me as it only touches rpi

@huceke huceke merged commit 4d7c659 into xbmc:master
@popcornmix popcornmix added a commit to popcornmix/xbmc that referenced this pull request
@popcornmix popcornmix [rbp] Enable Vsync as a default
This was done in #2388, but got lost in the setting refactor and is currently disabled
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 7, 2013
  1. @popcornmix
Showing with 1 addition and 1 deletion.
  1. +1 −1 xbmc/settings/Settings.h
2 xbmc/settings/Settings.h
@@ -36,7 +36,7 @@
#ifdef MID
#else // MID
-#if defined(TARGET_DARWIN) || defined(_WIN32)
+#if defined(TARGET_DARWIN) || defined(_WIN32) || defined(TARGET_RASPBERRY_PI)
Something went wrong with that request. Please try again.