Fixing this fully would be a significant change, probably in libmirclient logic. We'd need to implement code to replace the underlying buffer a client has _after_ they have been given it by swapping. This can only work if we can detect whether the client has started rendering to the buffer or not. So I don't know.
Simpler solutions might be possible, whereby we just synthesize MirResizeEvent in a way that guarantees it agrees with what's coming in the next SwapBuffers. Come to think of it, since Mir is switching to double buffers in release 0.12, this might just happen by default. So long as you never make the assumption that the new size is available before you SwapBuffers, then the new double buffering in 0.12 might just solve this.
No news, maybe.
Fixing this fully would be a significant change, probably in libmirclient logic. We'd need to implement code to replace the underlying buffer a client has _after_ they have been given it by swapping. This can only work if we can detect whether the client has started rendering to the buffer or not. So I don't know.
Simpler solutions might be possible, whereby we just synthesize MirResizeEvent in a way that guarantees it agrees with what's coming in the next SwapBuffers. Come to think of it, since Mir is switching to double buffers in release 0.12, this might just happen by default. So long as you never make the assumption that the new size is available before you SwapBuffers, then the new double buffering in 0.12 might just solve this.