Ah, that completely went over my head.

In that case, there's a symptom of a much bigger problem. You should never feed back on ConfigureNotify events by calling XResizeWindow or XConfigureWindow. In that case, the XBMC_VIDEORESIZE event calling back through to SetWindow, at least in its current incarnation, is incorrect. It isn't something that can really be worked around by tracking if we received an event recently because you'll run into some interesting race conditions doing that.

It seems to be that SetWindow is being called for two reasons
 * To resize the window in case we didn't want to change outputs or screens
 * To completely destroy and recreate the window on output changes

It seems to me that perhaps responding to ConfigureNotify events with SetWindow might make sense for the first case - but certainly not the second (as the window was already resized). It seems like the best approach is to split SetWindow into RefreshWindow (destroys and re-creates the window as necessary) and SendResizeRequestForWindow (which asks the server to resize the window). Don't call SendResizeRequestForWindow from CWinSystemX11::ResizeWindow :)