It's usually a solution for devs that can't solve issue with bad framepacing (which on PC is one of methods to fix frame tearing on 60Hz monitors)
It forces game to make one frame in advance so it smooths out frame pacing at the cost of not fluid FPS drops - if they happen. So it shouldn't be used for games that aren't optimized on very very good level.
So only available FPS values for XC3 with double buffer enabled are multipliers of FPS target which is 60. If it would be 30, it wouldn't drop to 20 FPS but straight to 15 FPS.
60 FPS | | 30 FPS |
[...]
180 - 3:1
120 - 2:1
60 - 1:1
30 - 1:2
20 - 1:3
15 - 1:4
12 - 1:5
10 - 1:6
|
| [...]
90 - 3:1
60 - 2:1
30 - 1:1
15 - 1:2
10 - 1:3 |
There is nothing in between.
What you see as "28" or whatever are just results of game jumping between 20 and 30 target in one second.
That's why any FPS drop is heavily visible here (one frame drop means game for time of at least two frames jumps to 20 FPS frametime).
XC3 engine is optimized pretty well, it lacks only just a bit of CPU and GPU to get solid handheld experience - but it's pulled down by double buffer. Dunno why they didn't eliminate it yet - they clearly are working on it since they introduced frameskipping in engine since XCDE, but I guess syncing effects is a bitch.
Double buffer is notorious in games made by Nintendo owned studios, but they can use it since they have very well optimized games - if they are using their own engines made with Lunchpack.