This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.15
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2014-02-04 15:57:21 +0000, wrote:

SDL_VIDEO_X11_BACKINGSTORE has no effect anymore (since years) , and having BACKINGSTORE enabled everytime may lead to tearing effect with newer Xorg servers if composite extension is enabled.

This comment makes me think that there is no point in leaving it in that state:

#if 0 /* This is an experiment - are the graphics faster now? - nope. */
if ( SDL_getenv("SDL_VIDEO_X11_BACKINGSTORE") )
#endif

On 2014-02-20 00:07:02 +0000, harry rod wrote:

unset SDL_VIDEO_X11_BACKINGSTORE fixes tearing on intel igpu with xbmc for me

On 2014-03-04 21:01:08 +0000, Adam Jackson wrote:

Since I'm the person most nearly responsible for the X side of this problem, I'll add some background here.

Way back in 2007 (a bit before xserver 1.4) I rewrote X's bs implementation in terms of some of the Composite extension's internal machinery; automatic redirection in the Composite sense is equivalent to core backing store's WhenMapped state, so it made sense to do the one in terms of the other. What I didn't do then, though I'd intended to, was automatically advertise that backing store support if the Composite extension was enabled; you needed to still explicitly enable it in xorg.conf for the server to advertise the support.

In 1.15 I finally fixed that up, so now the server claims to support backing store if the Composite extension is enabled (and it usually is). This was intended to be a convenience for legacy applications that - arguably brokenly - require backing store support to work correctly because they don't bother to implement an Expose handler.

The automatic redirection code, however, is basically just XCopyArea. It doesn't know what a vblank is, it can't synchronize updates with the retrace, hence the tearing. The old pre-1.4 BS code was not any better in that respect. The only reason you might want BS is if you're not running a compositor (hence wouldn't have vsync anyway), and even then it's a tradeoff, implicit double-buffering on the server side versus marginally less tearing and possibly not needing a proper Expose handler. I can't speak to whether working Expose handlers are common for SDL apps, but naively I would expect they're not common, that SDL apps default to being "like fullscreen" and don't expect to repaint things due to window system events.

So at a bare minimum I would suggest checking whether there's a compositor running on the screen already, and defaulting BS to off if there is. The code to do that is approximately:

char *s = asprintf("_NET_WM_CM_S%d", screen);
Atom a = XInternAtom(dpy, s);
Window w = XGetSelectionOwner(dpy, a);

if (w) /* compositor running */ ;

If possible I would suggest deferring the decision about BS-or-not to the point where you know what kind of rendering you're going to do, if that's a thing you can know. It's almost never going to be useful for GL clients.

On 2014-03-05 04:59:40 +0000, Sam Lantinga wrote:

Thanks for the info, that's very useful! :)

On 2014-03-05 05:06:07 +0000, Sam Lantinga wrote:

We don't have a release of SDL 1.2 planned, and Ryan is actively working on a binary compatible 1.2 API built on top of SDL 2.0, which doesn't have this problem.

I'm assigning this bug to Ryan just so he sees it and can update it when the 1.2 API on top of SDL 2.0 is available.

On 2018-08-13 07:21:32 +0000, Rene Dudfield wrote:

Arch Linux patches SDL for this issue here: https://git.archlinux.org/svntogit/packages.git/tree/trunk/SDL-1.2.15-no-default-backing-store.patch?h=packages/sdl