Hi,
Let’s take, for example, snes9x2010 and snes9x: this case is specially interesting because snes9x2010 is slower than snes9x (yes, slower!) in low-latency mode. I have both cores working on my Raspberry PI 3. Now, if I use max_swapchain=2 to shave off 1 frame of input lag, snes9x2010 is VERY slow! On the other hand, the naturally slower snes9x is perfect except for hi-res screens where CPU usage is on the limit (Seiken Densetsu 3 character selection screen, for example).
Note snes9x2010 CPU usage is not high at all: it’s just slow when double-buffered video is in use (max_swapchains=2). On the other hand, snes9x is using ~80% cpu sometimes and it’s smooth as silk except for the mentioned hi-res screens.
Using (more laggy) max_swapchains=3, snes9x2010 performs normal, faster than snes9x core as expected in the situations where snes9x takes CPU to the limit.
This can also be seen in blueMSX, where CPU usage is low ~30%, and MK1-MK1 games in MAME2003.
There’s NO problem on the driver side (I implemented the double-buffering mechanism myself on some of these drivers), and the same thing happens in GL on KMS mode, plain dispmanx or GL on dispmanx (default Rpi video mode). I know that double-buffering is a trade-off where we are more exposed to system jittering, but I run my cores on isolated CPUs, where that’s not a problem at all.
What’s wrong with these cores and double-buffering? What makes them different? Most cores work VERY well in double-buffering mode, except those. Maybe they have different internal buffering mechanisms that prevent them to run well in double-buffered mode?